469,270 Members | 1,031 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,270 developers. It's quick & easy.

Qry : Behaviour of fgets -- ?


Machine 1 :
bash-3.00$ uname -a
SunOS <hostname5.10 Generic_118822-30 sun4u sparc SUNW,Sun-Fire-280R

bash-3.00$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/
specs
gcc version 2.95.3 20010315 (release)
Machine 2:
bash-2.05b$ uname -a
Linux <hostname2.4.21-4.EL #1 Fri Oct 3 18:13:58 EDT 2003 i686 i686
i386 GNU/Linux

bash-2.05b$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-
redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20)

bash-2.05b$ cat fgets_fail_test.c
#include<stdio.h>
#include <string.h>
#include<stdlib.h>

/* Demo fgets failed by Raxit Sheth & Gaurav Gupta */

int main()
{
char spcontent[100],sendrepfile[100];
FILE *spfp=NULL;
memset(sendrepfile,0,100);
strcpy(sendrepfile,"/tmp/filenotexists");
if ((spfp = fopen(sendrepfile, "r")) == (FILE *)NULL)
{
printf("error in opening file %s",sendrepfile);fflush(stdout);
}
memset(spcontent, 0, sizeof(spcontent));

while (fgets(spcontent,40, spfp)!=NULL)
{
printf("The value of spcontent is
[%s]",spcontent);fflush(stdout);;
}
return 0;
}
<simillar core dump occurs on both the system>
bash-2.05b$ gcc -Wall fgets_fail_test.c -o test
bash-2.05b$ ./test
error in opening file /tmp/filenotexistsSegmentation fault (core
dumped)
bash-2.05b$ gdb ./test ./core.27887
GNU gdb Red Hat Linux (5.3.90-0.20030710.40rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging
symbols found)...Using host libthread_db library "/lib/tls/
libthread_db.so.1".

Core was generated by `./test'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/tls/libc.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0xb7506444 in fgets () from /lib/tls/libc.so.6
(gdb) where
#0 0xb7506444 in fgets () from /lib/tls/libc.so.6
#1 0x0804854b in main ()
(gdb) frame 0
#0 0xb7506444 in fgets () from /lib/tls/libc.so.6
(gdb) print errno
Cannot access memory at address 0xb74a7008
char *fgets(char *s, int n, FILE *stream)
Qry : What is the Behaviour if stream is NULL. ?

As per our understanding fgets should return NULL < and internally
gets should put check on stream, if it is not NULL then only should do
additional access of stream.

please ignore if it is known and would be great if you can point out
in the implementation detail.
--Gaurav Gupta & Raxit Sheth
http://www.barcamp.org/BarCampMumbaiOct2007 <----BarCampMumbaiOct2007

Sep 6 '07
285 7848
"Kenneth Brody" <ke******@spamcop.netwrote in message
news:46***************@spamcop.net...
Wojtek Lerch wrote:
>"Charlie Gordon" <ne**@chqrlie.orgwrote in message
news:46***********************@news.free.fr...
static char dummy_file_object[1] = "";
FILE *dummy_file_pointer = (FILE *)&dummy_file_object;

That doesn't work if FILE has non-trivial alignment requirements.

Does alignment matter if the pointer is never dereferenced?
Yes.

6.3.2.3#7 "A pointer to an object or incomplete type may be converted to a
pointer to a different object or incomplete type. If the resulting pointer
is not correctly aligned for the pointed-to type, the behavior is
undefined."

Sep 11 '07 #151
On Tue, 11 Sep 2007 12:46:42 -0400, Kenneth Brody wrote:
"Casper H.S. Dik" wrote:
>The hoops we have to jump through in 32 bit space to add additional
data are not pretty.

Is this a valid FILE definition?

typedef struct
{
struct _OPAQUE_FILE *private;
}
FILE;
Yes, and so is typedef unsigned char[_FILESIZE] FILE;
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes” feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

Sep 11 '07 #152
On Tue, 11 Sep 2007 12:43:17 -0400, Kenneth Brody wrote:
>That doesn't work if FILE has non-trivial alignment requirements.

Does alignment matter if the pointer is never dereferenced? From
context, I assume its sole purpose is as a value to be stored and
compared against. You know that the address is valid, so it can't
be a trap representation.
Simply casting a pointer to a pointer to a different type causes
UB if it points to memory not aligned for the latter type.
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes” feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

Sep 11 '07 #153
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:
>In article <46****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:
>However to be able to supply getc and putc as macros, with a FILE*
argument, it is necessary that FILE be a complete type. However it
is the height of foolishness to use this description, which would
be available in stdio.h.
>Not necessarily. getc() and so on can use unsigned char * hackery in a
way which is legal and reasonable for the implementation, but not for
the user-programmer.

What "unsigned char *" hackery is needed?

Not necessary, but sufficient.
>If FILE is an incomplete type, getc() can just cast its argument to
(say) _FILE *.

True, but in that case you might as well make FILE a complete type.
Making it incomplete would make it more difficult for programs to
abuse it by declaring FILE objects. We can't prevent perverse
programmers from examining the expansion of the getc() macro and
messing around with the internals of _FILE< but we can make it less
convenient. Or we could, if FILE were permitted to be incomplete.

This isn't a huge deal (i.e., I don't consider it to be a bug in the
standard), but IMHO it would make sense for a future standard to allow
FILE to be an incomplete type. It wouldn't break any existing code
that doesn't deserve to be broken.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 11 '07 #154
Keith Thompson wrote:
>
Making it incomplete would make it more difficult for programs to
abuse it by declaring FILE objects. We can't prevent perverse
programmers from examining the expansion of the getc() macro and
messing around with the internals of _FILE< but we can make it less
convenient.
typedef struct FILE {char dummy;} FILE;

Make messing with the internals as inconvenient as the incomplete type:

typedef struct FILE FILE;

An incomplete type would be less "artificial", I agree, but we can keep it
as fool proof as with an incomplete type.

--
You can contact me at <ta*****************@yahoDELETETHATo.fr>
Sep 11 '07 #155
"Charlie Gordon" <ne**@chqrlie.orgwrites:
"Douglas A. Gwyn" <DA****@null.neta crit dans le message de news:
46***************@null.net...
>Richard Bos wrote:
>>On strcpy(), yes, but on fgets()? A char * and a FILE * can only overlap
if a. you're invoking UB anyway, by scribbling wildly into the FILE
object through a mispointed char *, or b. you're invoking UB anyway, by
scribbling neatly into the FILE object using undefined and unportable
assumptions about the layout of the FILE.

Um, no, consider fgets((char *)(void *)fp, (int)sizeof(FILE), fp);
while it may be a stupid thing to do, if no further use is made
of the associated stream it would have been allowed, and the
implementation would have to make it work, which means making
a copy of the FILE structure before starting the transfer.
By prohibiting overlap of the pointed-to objects, we assure
the implementor that he doesn't have to worry about that.

nonsense!

and of course fread(fp, sizeof FILE, 1, fp) invokes UB as well, no need to
sprinkle prototypes with useless keywords to spell the obvious.
It's obvious to you and to me, but it's not obvious to the compiler.
If this is the kind of issue on which the commitee focusses between releases
of the Standard, the situation is hopeless.
Everybody here knows that the FILE object and the buffer will never
actually overlap in real code, and that if they do, it's (almost?)
certainly the result of something that invokes undefined behavior
anyway. The point of the 'restrict' qualifiers is to convey that
"obvious" knowledge to the compiler. This might enable the compiler
to generate slightly better code; at worst, it should be harmless.

The point, I think, is that the 'restrict' qualifiers allow the
compiler to assume that the char* and FILE* arguments point to
non-overlapping memory. This might permit the compiler to generate
slightly better code in some cases. At worst, it should be harmless.

As a programmer, either writing a call to fgets() or implementing
fgets() itself, you can safely ignore the 'restrict' qualifiers.

It could be argued that pointer arguments should be restrict-qualified
unless there's a specific reason not to. Another incompatible C-like
language might even make 'restrict' the default, and require an
explicit qualifier when the arguments *might* point to overlapping
memory. (Doesn't Fortran do something like that?) Doing that for C
would have broken too much code.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 11 '07 #156
In comp.std.c Charlie Gordon <ne**@chqrlie.orgwrote:
>
C99RationaleV5.10 seems to be the "latest" version.
It is. There's a link to the latest version on the "standards" page of
the committee's web site:

<http://www.open-std.org/jtc1/sc22/wg14/www/standards>

-Larry Jones

Don't you hate it when your boogers freeze? -- Calvin
Sep 11 '07 #157
Keith Thompson wrote:

It could be argued that pointer arguments should be restrict-qualified
unless there's a specific reason not to. Another incompatible C-like
language might even make 'restrict' the default, and require an
explicit qualifier when the arguments *might* point to overlapping
memory. (Doesn't Fortran do something like that?)
Yes, Fortran does that. It generated endless flamewars about why Fortran
beats C at performances because "Fotran has no pointer", while in reality,
Fortran has disguised pointers, but they mustn't be aliased as function
arguments.

The questions about nested structures and pointers didn't exist in Fortran
77 as there were no structures or pointers to pointers (or even explicit
pointers/references).
Actually, avoiding aliasing issues was relatively straightforward.
Rule of thumb: Don't pass twice the *same* (as recognized by the variable
name) array in a function call.
Doing that for C
would have broken too much code.
Yes, of course.
However, one of the (pre-1999) C implementation I use has a non-conforming
option "Assume no pointer aliasing". It specifically does that. I didn't
understood this option (and never enabled it) until I read about the
restrict qualifier in C99.

--
You can contact me at <ta*****************@yahoDELETETHATo.fr>
Sep 11 '07 #158
Wojtek Lerch wrote:
Are you implying that
memset(stdin,6,sizeof(FILE));
is allowed, as long as no further use is made of stdin by the program?
It's not supposed to be allowed, but so far as I know the standard
neglected to specify that.

Anyway, to further develop the previous idea, I suppose
one could save the FILE object somewhere, clobber it without
performing any stdio operations, then restore the object
before proceeding. While not something to be emncouraged,
it could have been assumed that it is allowed (in a s.c.
program). Since this never came up for discussion that I
recall, a poll would have to be conducted to see what the
intent may have been, if any.
Sep 11 '07 #159
Kenneth Brody wrote:
Does alignment matter if the pointer is never dereferenced?
It might; it depends on the architecture.
Also, the C implementation might rely on the alignment
assumption when generating code for pointer conversion.
The following will not work properly on many word-addressed
platforms:
union t { int i; char c[2]; } u, *x;
char *p = &u.c[1]; *q;
x = (union t *)p; // might be allowed
q = (char *)x; // byte selector is lost
assert(p == q); // likely to fail!
Sep 11 '07 #160
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
The point, I think, is that the 'restrict' qualifiers allow the
compiler to assume that the char* and FILE* arguments point to
non-overlapping memory.
No they don't, except when they are in the function *definition*. In a mere
declaration, adding the restrict qualifier to parameters is as meaningless
as adding the const qualifier. The following program is strictly
conforming:

void fun( int *restrict p, int *restrict q );

int main( void ) {
int a = 0;
fun( &a, &a );
return a;
}

void fun( int *const x, int *const y ) {
*x = *y + 1;
*y = *x - 1;
}
This might permit the compiler to generate
slightly better code in some cases. At worst, it should be harmless.
Slightly better code for the function, but not for calls to the function.

Sep 11 '07 #161
"Andr Gillibert" <ta*****************@yahodeletethato.frwrites:
Keith Thompson wrote:
[...]
>Doing that for C would have broken too much code.

Yes, of course.
However, one of the (pre-1999) C implementation I use has a
non-conforming option "Assume no pointer aliasing". It specifically
does that. I didn't understood this option (and never enabled it)
until I read about the restrict qualifier in C99.
Interesting. For such an option to be really useful, there should be
a way to override it, perhaps a 'norestrict' or '_Norestrict'
qualifier. Otherwise, there would be no way to implement memmove().

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 11 '07 #162
"Wojtek Lerch" <Wo******@yahoo.cawrites:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>The point, I think, is that the 'restrict' qualifiers allow the
compiler to assume that the char* and FILE* arguments point to
non-overlapping memory.

No they don't, except when they are in the function *definition*. In
a mere declaration, adding the restrict qualifier to parameters is as
meaningless as adding the const qualifier. The following program is
strictly conforming:

void fun( int *restrict p, int *restrict q );

int main( void ) {
int a = 0;
fun( &a, &a );
return a;
}

void fun( int *const x, int *const y ) {
*x = *y + 1;
*y = *x - 1;
}
Is it? I know there's some kind of compatibility requirement for
function declarations and corresponding function definitions. For
example, using 'int' in the declaration and 'long' in the definition
would be illegal. Are differences in qualifiers allowed? Where are
the rules stated?

[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 11 '07 #163
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
"Wojtek Lerch" <Wo******@yahoo.cawrites:
>The following program is
strictly conforming:

void fun( int *restrict p, int *restrict q );
....
> fun( &a, &a );
....
> void fun( int *const x, int *const y ) {
....
Is it? I know there's some kind of compatibility requirement for
function declarations and corresponding function definitions. For
example, using 'int' in the declaration and 'long' in the definition
would be illegal. Are differences in qualifiers allowed? Where are
the rules stated?
6.7.5.3#15 "(In the determination of type compatibility and of a composite
type, each parameter declared with function or array type is taken as having
the adjusted type and each parameter declared with qualified type is taken
as having the unqualified version of its declared type.)"

Sep 12 '07 #164
"Wojtek Lerch" <Wo******@yahoo.cawrites:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>"Wojtek Lerch" <Wo******@yahoo.cawrites:
>>The following program is
strictly conforming:

void fun( int *restrict p, int *restrict q );
...
>> fun( &a, &a );
...
>> void fun( int *const x, int *const y ) {
...
>Is it? I know there's some kind of compatibility requirement for
function declarations and corresponding function definitions. For
example, using 'int' in the declaration and 'long' in the definition
would be illegal. Are differences in qualifiers allowed? Where are
the rules stated?

6.7.5.3#15 "(In the determination of type compatibility and of a
composite type, each parameter declared with function or array type is
taken as having the adjusted type and each parameter declared with
qualified type is taken as having the unqualified version of its
declared type.)"
Thanks.

What is the purpose of allowing the qualifiers to differ? Is it
specifically to allow qualifiers to be given for a function definition
(where they can affect the body of the function), but not in a
function declaration (where they're largely irrelevant)?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 12 '07 #165
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
"Wojtek Lerch" <Wo******@yahoo.cawrites:
>6.7.5.3#15 "(In the determination of type compatibility and of a
composite type, each parameter declared with function or array type is
taken as having the adjusted type and each parameter declared with
qualified type is taken as having the unqualified version of its
declared type.)"

What is the purpose of allowing the qualifiers to differ? Is it
specifically to allow qualifiers to be given for a function definition
(where they can affect the body of the function), but not in a
function declaration (where they're largely irrelevant)?
When the only qualifiers were "const" and "volatile", it made sense:

extern int fun( int x );

int fun( const int x ) { ... }

Sep 12 '07 #166
Charlie Gordon wrote:
>
.... snip ...
>
I am curious how much code does this in real life. As a code
reviewer, I would forbid using actual FILE structures for this
or any purpose.

Note that the same effet can be achieved without an actual FILE
structure, using a pointer instead of the address as the "special
value":
The standard already does this, forbidding direct access to a FILE
object. You can only pass FILE* objects back and forth to/from
system functions. However, there is a wee glitch. putc and getc
are allowed to be macros (for efficiency reasons), and thus have to
have a defined FILE object to work on. You are not supposed to
notice this, nor take any advantage of it, because it won't work on
the next system. However putc/getc macros are issued by the
implementor, and they can make suitable allowances.

Don't ask for C&V. The forbid is there, but I don't remember where.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 12 '07 #167
Wojtek Lerch wrote:
"CBFalconer" <cb********@yahoo.comwrote in message
>However to be able to supply getc and putc as macros, with a FILE*
argument, it is necessary that FILE be a complete type.

Couldn't the macros cast their FILE* argument to a pointer to
another, complete type?
What for? The purpose of putc/getc macros is to speed up access
and avoid using a local buffer, when the system buffer will serve
adequately. To do this you have to know how FILE is built. When
combined into a few routines, virtually all i/o, especially
interactive i/o, can be handled easily.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 12 '07 #168
"Kenneth Brody" <ke******@spamcop.neta crit dans le message de news:
46***************@spamcop.net...
Charlie Gordon wrote:
>>
"Peter J. Holzer" <hj*********@hjp.ata crit dans le message de news:
sl************************@zeno.hjp.at...
On 2007-09-09 23:28, Charlie Gordon <ne**@chqrlie.orgwrote:
[...]
>C libraries used to allocate FILE structures from a static array:
checking
for valid FILE pointers was pretty easy then. I would be surprised if
current implementations could no longer do this efficiently.

On many modern system there is no fixed limit on the number of open
files, so a static array isn't feasible. And once you start allocating
them individually, you either have to check all of them (which is not
efficient) or use a more complicated structure (like a binary tree)
only
this check.

Instead of allocating them individually, you can allocate them in chunks
of
increasing sizes, keeping the complexity of the test in logN, which is
still
quite efficient.

Well, you can't realloc() the array, as that would invalidate all
existing FILE* values. (Unless it returned the same address, which
is certainly not guaranteed, or even very likely in most scenarios.)
Of course! I was not suggesting using realloc.
You can, however, allocate chunks of fixed-sized arrays which are then
put on a linked list. Not as efficient as a single array, but a lot
more efficient than individual allocations.
Yes, but the complexity is still linear: the number of comparisons against
array bounds is proportional to the total number of FILE objects allocated
(2 * N / chunksize).
The trick is to allocate chunks of increasing sizes for instance by doubling
the chunk size each time you run out of objects: the number of chunks will
be Log_base_2(N / first_chunk_size), a much smaller value for large values
of N. The chunks would be linked in a list and fclosed FILEs linked in a
free list. Alternately, one can store pointers to the chunks in a small
array to make the test more cache efficient.

You can use that method for any type of fixed size structure that a program
allocates, and add debug time asserts to verify pointer validity. There are
2 constraints: any 2 object pointers (converted to char *) must be
comparable (not guaranteed by the Standard) and you need a way to tell that
a freed or unallocated structure is valid (either a dedicated flag or some
other test of field values). This is not 100% foolproof, but can help debug
allocation problems when more general tools are not available.

There are other efficient methods for pointer validity checking, using hash
tables, trees or similar ad hoc structures, usually with more complexity.

--
Chqrlie.
Sep 12 '07 #169
Keith Thompson <ks***@mib.orgwrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:
If FILE is an incomplete type, getc() can just cast its argument to
(say) _FILE *.
True, but in that case you might as well make FILE a complete type.

Making it incomplete would make it more difficult for programs to
abuse it by declaring FILE objects. We can't prevent perverse
programmers from examining the expansion of the getc() macro and
messing around with the internals of _FILE< but we can make it less
convenient. Or we could, if FILE were permitted to be incomplete.

This isn't a huge deal (i.e., I don't consider it to be a bug in the
standard), but IMHO it would make sense for a future standard to allow
FILE to be an incomplete type. It wouldn't break any existing code
that doesn't deserve to be broken.
Oh, I can certainly agree with that.

Richard
Sep 12 '07 #170
"Wojtek Lerch" <Wo******@yahoo.caa crit dans le message de news:
5k************@mid.individual.net...
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>The point, I think, is that the 'restrict' qualifiers allow the
compiler to assume that the char* and FILE* arguments point to
non-overlapping memory.

No they don't, except when they are in the function *definition*. In a
mere declaration, adding the restrict qualifier to parameters is as
meaningless as adding the const qualifier. The following program is
strictly conforming:

void fun( int *restrict p, int *restrict q );

int main( void ) {
int a = 0;
fun( &a, &a );
return a;
}

void fun( int *const x, int *const y ) {
*x = *y + 1;
*y = *x - 1;
}
> This might permit the compiler to generate
slightly better code in some cases. At worst, it should be harmless.

Slightly better code for the function, but not for calls to the function.
That's exactly my point.

There are even simpler examples to prove the compiler cannot issue
appropriate warnings from the restrict keyword alone in the function
declaration:

char buf[100];
int n;

memcpy(buf, buf, 0) // OK
memcpy(buf + 10, buf, 10); // OK
memcpy(buf + 10, buf, 20); // not OK
memcpy(buf + 10, buf, n); // cannot tell at compile time!
memmove(buf + 10, buf, n); // cannot tell at compile time either.

restrict qualifiers in function declarations convey no useful information to
the compiler.
the information conveyed to the programmer is minimal and vastly
misunderstood.

While it may not necessaarily be considered a defect, it was not a necessary
addition either.

In particular, I do not see the point of adorning the parameters of fopen
with restrict qualifiers: it is a useless constraint, meaningless for two
const char * . C99 6.7.3.1p10 example 3 clearly shows that unmodified
objects can be aliased through multiple restricted pointers. In this case,
I call for removal.

--
Chqrlie.
Sep 12 '07 #171
Keith Thompson wrote:
"Andr Gillibert" <ta*****************@yahodeletethato.frwrites:
>Yes, of course.
However, one of the (pre-1999) C implementation I use has a
non-conforming option "Assume no pointer aliasing". It specifically
does that. I didn't understood this option (and never enabled it)
until I read about the restrict qualifier in C99.

Interesting. For such an option to be really useful, there should be
a way to override it, perhaps a 'norestrict' or '_Norestrict'
qualifier.
There was non _Norestrict or equivalent keyword.
However, the option could be overriden in individual translation units.
Otherwise, there would be no way to implement memmove().
Indeed, in a TU using this option it wasn't possible to deal with
aliasing, except with manual equality pointer tests, but that wouldn't
work with memmove.

An equivalent of memmove() would have to be implemented in a different TU.

That's why C99 restrict keyword is much more practical.

--
You can contact me at <ta*****************@yahoDELETETHATo.fr>
Sep 12 '07 #172
"Douglas A. Gwyn" <DA****@null.netwrites:
Kenneth Brody wrote:
Does alignment matter if the pointer is never dereferenced?

It might; it depends on the architecture.
Also, the C implementation might rely on the alignment
assumption when generating code for pointer conversion.
The following will not work properly on many word-addressed
platforms:
union t { int i; char c[2]; } u, *x;
char *p = &u.c[1]; *q;
x = (union t *)p; // might be allowed
q = (char *)x; // byte selector is lost
assert(p == q); // likely to fail!
I'm interested, do you know one implementation on a word adressed platform
which used a byte selector which didn't use otherwise unused bits in other
pointers?

My perception was that the current word-addressed platforms used
sizeof(char)==sizeof(word) and so had no byte selector: breaking this too
common assumption doesn't bring anything on these targets not aimed at
caracter handling.

On vintage computers, the only word addressable platform I know which had C
compilers with sizeof(char) != sizeof(word) is the PDP-10. But there other
reasons (some specific to the platform, see
du********************************@4ax.com) made the implementation I used
choose a unique pointer size for everything. And these technical reasons
apply to the other vintage word-addressed architectures I know; but I don't
know them all.
Yours,

--
Jean-Marc
Sep 12 '07 #173
On Tue, 11 Sep 2007 12:46:42 -0400, Kenneth Brody wrote:
"Casper H.S. Dik" wrote:
>The hoops we have to jump through in 32 bit space to add additional
data are not pretty.

Is this a valid FILE definition?

typedef struct
{
struct _OPAQUE_FILE *private;
}
FILE;
Yes, and so is typedef unsigned char FILE[_FILESIZE];
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes” feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

Sep 12 '07 #174
CBFalconer <cb********@yahoo.comwrites:
Richard Bos wrote:
>Rainer Weikusat <rw*******@mssgmbh.comwrote:
>>Keith Thompson <ks***@mib.orgwrites:
We don't claim (except jokingly) that executing those statements
*will* cause demons to fly out of your nose. The claim is merely
that nasal demons are one of the infinitely many behaviors
permitted by the standard.

It is one of the infinitely many things humans make up because
something like an inbred horror vacui compels them to fill any
void with something. But any example of "behaviour" is
necessarily defined and not undefined.

You have obviously never read much about quantum physics. And yes,
when the Standard does not define what a piece of code does but
leaves it up to the compiler, and when that compiler does not care
to make sure that that code does something specific but leaves it
up to the accidents of microprocessor behaviour (which both could
very well do, and with good reason), then quantum physics really
can toss the coin about how that code behaves, on that day, on
that computer.

My compilers exercise a random generator on each ++ (or --) call.
If two of them on the same object occur between sequence points it
uses the last random value to select a function to call. This can
be any function in any process, live or not (and requires system
specific code). This produces an amazing density of nasal demons.
Someday it may well launch WWIII. It is standard conforming.
This text would fit into a newsgroup whose topic is production of
mildly creative absurd fiction or one discussing quirks of a
particular implementation of C BUT NOT into a discussion of C, because
it is only insofar related to it as it talks about something the
C-standard does not talk about. And 'C' is the set of things the
C-standard DOES talk about.

One would assume that this cannot be that complicated for someone
trying to understand it, ie someone whose motivation is not the very
production of mildly creative absurd fiction.
Sep 12 '07 #175
Harald van Dijk wrote:
I didn't say "the laws of physics as discovered (so far)", I copied Bart van
Ingen Schenau's unqualified "the laws of physics", which do exist even if
we don't fully know them yet.
I don't see that that's necessarily the case.

What's more, if there /are/ actual laws, we don't (and, I think, can't)
know what they are. So it doesn't matter; all we can work with is the
"laws" of physics, ie, our best-tested conjectures.

--
Chris "Popperian" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Sep 12 '07 #176
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>>However to be able to supply getc and putc as macros, with a FILE*
argument, it is necessary that FILE be a complete type.
>Couldn't the macros cast their FILE* argument to a pointer to
another, complete type?
>What for?
So that they can work wothout FILE being a complete type. You said it
had to be one so that getc() and putc() could be macros; but that's not true
because the definition of getc() could cast the FILE * to, say, _FILE *,
where _FILE is the complete type.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Sep 12 '07 #177
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>Making it incomplete would make it more difficult for programs to
abuse it by declaring FILE objects. We can't prevent perverse
programmers from examining the expansion of the getc() macro and
messing around with the internals of _FILE< but we can make it less
convenient. Or we could, if FILE were permitted to be incomplete.
You can't prevent perverse programmers from doing anything. They're
too determined. If getc() can see the internals, so can anyone with
sufficiently poor taste.

I think the advantage of making FILE an incomplete type would be more
to prevent inexperienced programmers from making mistakes about what
is legal, such as trying to copy a FILE object (which may or may not
work depending on the implementation).

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Sep 12 '07 #178
"Richard Tobin" <ri*****@cogsci.ed.ac.ukwrote in message
news:fc***********@pc-news.cogsci.ed.ac.uk...
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>>>However to be able to supply getc and putc as macros, with a FILE*
argument, it is necessary that FILE be a complete type.
>>Couldn't the macros cast their FILE* argument to a pointer to
another, complete type?
>>What for?

So that they can work wothout FILE being a complete type. You said it
had to be one so that getc() and putc() could be macros; but that's not
true
because the definition of getc() could cast the FILE * to, say, _FILE *,
where _FILE is the complete type.
That's exactly what my reply was going to be. Thanks.

Sep 12 '07 #179
On Tue, 11 Sep 2007 03:59:04 +0000, Richard Heathfield wrote:
No, they don't. Nature has no laws. Nature has behaviour. We observe
that behaviour, and formulate "laws" which explain it. Nature, however,
is under no obligation to observe those "laws" (and indeed frequently
breaks them). For example, the vast majority of gases don't observe the
gas laws.
<topicality level="LDBL_MIN">
They are approximate laws. There are laws which instead are
believed to be exact (e.g. the conservation of electrical charge).
So even if the Standard doesn't forbid

char *str = "Hey!";
size_t len = strlen(str);
struct flexible {
size_t size;
char data[1];
} *word = malloc(sizeof *word + len);
if (word != NULL) {
word->size = len;
strcpy(word->data, str);
puts(word->data);
}

from causing all electrons in my body to turn into positrons, I
am quite confident that this won't happen.
</topicality>
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes” feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

Sep 12 '07 #180
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
>In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>>>However to be able to supply getc and putc as macros, with a FILE*
argument, it is necessary that FILE be a complete type.
>>Couldn't the macros cast their FILE* argument to a pointer to
another, complete type?
>>What for?
>So that they can work wothout FILE being a complete type. You said it
had to be one so that getc() and putc() could be macros; but that's not true
because the definition of getc() could cast the FILE * to, say, _FILE *,
where _FILE is the complete type.
The implementor knows the offsets of the structure members. His getc
could cast the FILE * to unsigned char *, add the offset and cast to
the member's type. That's effectively what his compiler is going to
do in any case. But again, the library function need not be in C, so
the implementor doesn't have to use C hackery to get the right result.
The internal structure of a FILE is necessarily
implementation-dependent, so there's no reason any FILE function
should be ISO C.

As someone else pointed out, an implementor can't hide a structure
from a sufficiently perverse and determined programmer with a
decompiler. But that's true of any opaque type; it doesn't affect the
usefulness of opacity.

--
dhs sp*****@panix.com
Sep 12 '07 #181
On Mon, 10 Sep 2007 22:01:08 +0200, Harald van Dijk wrote:
That's a bold claim. With fgets, it would work on my implementation. With
strlen for example, it would not, because <string.h>'s macro definition of
strcpy refers to it by name. Are you sure no implementation does anything
similar with fgets?
Just curious, how does it define strcpy in terms of strlen while
evaluating each argument exactly once?
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes” feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

Sep 12 '07 #182
Richard Tobin wrote:
CBFalconer <cb********@maineline.netwrote:
>>>However to be able to supply getc and putc as macros, with a
FILE* argument, it is necessary that FILE be a complete type.

Couldn't the macros cast their FILE* argument to a pointer to
another, complete type?

What for?

So that they can work wothout FILE being a complete type. You
said it had to be one so that getc() and putc() could be macros;
but that's not true because the definition of getc() could cast
the FILE * to, say, _FILE *, where _FILE is the complete type.
But the only point of the macros is to access the internal
structure of the FILE object for such items as buffer usage
counters, etc. It also has to be able to call some routine to
refill the buffers when exhausted. The point of the macro is not
to have a macro, but to increase the system performance level.
_FILE knows nothing about these, and is thus useless.

Please don't strip attributions (the "Joe wrote" initial lines) for
any material you quote.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 12 '07 #183
"CBFalconer" <cb********@yahoo.comwrote in message
news:46***************@yahoo.com...
Richard Tobin wrote:
>CBFalconer <cb********@maineline.netwrote:
>>>>However to be able to supply getc and putc as macros, with a
FILE* argument, it is necessary that FILE be a complete type.

Couldn't the macros cast their FILE* argument to a pointer to
another, complete type?

What for?

So that they can work wothout FILE being a complete type. You
said it had to be one so that getc() and putc() could be macros;
but that's not true because the definition of getc() could cast
the FILE * to, say, _FILE *, where _FILE is the complete type.

But the only point of the macros is to access the internal
structure of the FILE object for such items as buffer usage
counters, etc. It also has to be able to call some routine to
refill the buffers when exhausted. The point of the macro is not
to have a macro, but to increase the system performance level.
_FILE knows nothing about these, and is thus useless.
The original argument was whether it's necessary for FILE to be a complete
type for putc and gets to be implemented as macros. The counterargument was
that it's not, because it's possible for the macros to use a different,
complete type. It wasn't about whether it's useful or practical, it was
about whether it's possible.

Whether it's practical is another story. I can think of an example where
FILE is the whole structure and is only defined as a complete type in the
implementor's private header, and _FILE is a smaller structure that contains
ony those members that are needed by the macros. For instance:

In <stdio.h>:

typedef struct _BIGFILE FILE;
typedef struct _SMALLFILE {
char *ptr, *end;
} _FILE;

#define getc( fp ) ( ((_FILE*)(fp)) -ptr != ((_FILE*)(fp)) -end ?
*((_FILE*)(fp))->ptr++ : _Getc(fp) )

In the library:

struct _BIGFILE {
_FILE header;
// More stuff here
};

Of course, it might make even more sense for the implementor to define FILE
to be the small structure and make the big structure a completely private
type in the library, but that is largely a matter of taste.

Sep 12 '07 #184
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>So that they can work wothout FILE being a complete type. You
said it had to be one so that getc() and putc() could be macros;
but that's not true because the definition of getc() could cast
the FILE * to, say, _FILE *, where _FILE is the complete type.
>But the only point of the macros is to access the internal
structure of the FILE object for such items as buffer usage
counters, etc. It also has to be able to call some routine to
refill the buffers when exhausted. The point of the macro is not
to have a macro, but to increase the system performance level.
_FILE knows nothing about these, and is thus useless.
_FILE would contain the real fields.

This is getting tedious, so here's a sketch of an extract from stdio.h:

typedef struct FILE FILE;

typedef struct _FILE {
unsigned char *buf;
insigned char *pos;
int count;
...
} _FILE;

#define getc(f) (((_FILE *)(f))->count-- 0 ?
(int)*((_FILE *)(f))->pos++ :
getc(f))

It's just like it would be if FILE was the complete type, but with
casts to _FILE * everywhere.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Sep 12 '07 #185
On Wed, 12 Sep 2007 15:19:01 +0200, Army1987 wrote:
On Mon, 10 Sep 2007 22:01:08 +0200, Harald van Dijk wrote:
>That's a bold claim. With fgets, it would work on my implementation.
With strlen for example, it would not, because <string.h>'s macro
definition of strcpy refers to it by name. Are you sure no
implementation does anything similar with fgets?
Just curious, how does it define strcpy in terms of strlen while
evaluating each argument exactly once?
By only using the execution path that calls strlen when the argument is a
constant. The as-if rule allows the argument to be evaluated multiple
times, so long as a correct program cannot tell the difference.
Reformatted a bit for readabiliy, it looks like this:

#define strcpy(dest, src) \
(__extension__ (__builtin_constant_p (src) \
? (__string2_1bptr_p (src) \
&& strlen (src) + 1 <= 8 \
? __strcpy_small (dest, \
__strcpy_args (src), \
strlen (src) + 1) \
: (char *) memcpy (dest, src, \
strlen (src) + 1)) \
: strcpy (dest, src)))
Sep 12 '07 #186
Rainer Weikusat <rw*******@mssgmbh.comwrites:
CBFalconer <cb********@yahoo.comwrites:
[...]
>My compilers exercise a random generator on each ++ (or --) call.
If two of them on the same object occur between sequence points it
uses the last random value to select a function to call. This can
be any function in any process, live or not (and requires system
specific code). This produces an amazing density of nasal demons.
Someday it may well launch WWIII. It is standard conforming.

This text would fit into a newsgroup whose topic is production of
mildly creative absurd fiction or one discussing quirks of a
particular implementation of C BUT NOT into a discussion of C, because
it is only insofar related to it as it talks about something the
C-standard does not talk about. And 'C' is the set of things the
C-standard DOES talk about.

One would assume that this cannot be that complicated for someone
trying to understand it, ie someone whose motivation is not the very
production of mildly creative absurd fiction.
We're talking about things that the C standard *explicitly* declines
to talk about. The motivation of these specific (admittedly absurd)
examples is to illuminate just what "undefined behavior" means.

Too many newbies assume that
int i = 3;
i = i++;
can only set i to 3 or to 4, and cannot possibly have any other
effect. Saying that this code may instead print "a suffusion of
yellow" in a conforming implementation is a statement about C, and it
illustrates something that's very important for C programmers to
understand.

If you dislike the "nasal demons" metaphor, that's fine, but there is
a real point to it; we're not just messing around.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 12 '07 #187
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>Making it incomplete would make it more difficult for programs to
abuse it by declaring FILE objects. We can't prevent perverse
programmers from examining the expansion of the getc() macro and
messing around with the internals of _FILE< but we can make it less
convenient. Or we could, if FILE were permitted to be incomplete.

You can't prevent perverse programmers from doing anything. They're
too determined. If getc() can see the internals, so can anyone with
sufficiently poor taste.
Right, and the price they pay is that their code breaks when ported to
another implementation, or when the declaration of FILE changes.
I think the advantage of making FILE an incomplete type would be more
to prevent inexperienced programmers from making mistakes about what
is legal, such as trying to copy a FILE object (which may or may not
work depending on the implementation).
Exactly.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 12 '07 #188
Army1987 <ar******@NOSPAM.itwrites:
On Tue, 11 Sep 2007 03:59:04 +0000, Richard Heathfield wrote:
>No, they don't. Nature has no laws. Nature has behaviour. We observe
that behaviour, and formulate "laws" which explain it. Nature, however,
is under no obligation to observe those "laws" (and indeed frequently
breaks them). For example, the vast majority of gases don't observe the
gas laws.

<topicality level="LDBL_MIN">
They are approximate laws. There are laws which instead are
believed to be exact (e.g. the conservation of electrical charge).
So even if the Standard doesn't forbid

char *str = "Hey!";
size_t len = strlen(str);
struct flexible {
size_t size;
char data[1];
} *word = malloc(sizeof *word + len);
if (word != NULL) {
word->size = len;
strcpy(word->data, str);
puts(word->data);
}

from causing all electrons in my body to turn into positrons, I
am quite confident that this won't happen.
All the electrons in your body could turn into positrons without
violating the conservation of electrical charge, as long as an
appropriate number of negatively charged particles are also created.

Fewer things are impossible than you might assume.
</topicality>
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 12 '07 #189
On Wed, 12 Sep 2007 11:45:48 -0700, Keith Thompson wrote:
Army1987 <ar******@NOSPAM.itwrites:
><topicality level="LDBL_MIN">
All the electrons in your body could turn into positrons without
violating the conservation of electrical charge, as long as an
appropriate number of negatively charged particles are also created.

Fewer things are impossible than you might assume.
Should've said "...without creating any other negatively charged
particle". However, I acknowledge that the scenario you describe
would be scary enough regardless of where those particles are
created.
></topicality>
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes” feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

Sep 12 '07 #190
Rainer Weikusat wrote:
....
This text would fit into a newsgroup whose topic is production of
mildly creative absurd fiction or one discussing quirks of a
particular implementation of C BUT NOT into a discussion of C, because
it is only insofar related to it as it talks about something the
C-standard does not talk about. And 'C' is the set of things the
C-standard DOES talk about.
It is perfectly on-topic to talk about what freedoms the standard
allows, just as much as it is on-topic to talk about what restrictions
it imposes. It is pointless to go into great details about the freedom
the standard allows when the behavior is undefined. But it is NOT
pointless to illustrute what "undefined behavior" means by giving
extreme examples.

Sep 12 '07 #191
On Wed, 12 Sep 2007 11:45:48 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:
>Army1987 <ar******@NOSPAM.itwrites:
><topicality level="LDBL_MIN">
They are approximate laws. There are laws which instead are
believed to be exact (e.g. the conservation of electrical charge).
So even if the Standard doesn't forbid
....
>from causing all electrons in my body to turn into positrons, I
am quite confident that this won't happen.

All the electrons in your body could turn into positrons without
violating the conservation of electrical charge,
Quite likely to violate conservation of mass, energy and momentum
tho...
>as long as an
appropriate number of negatively charged particles are also created.

Fewer things are impossible than you might assume.
Technically, nothing is impossible since the universe is infinite in
some dimension or other.
></topicality>
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Sep 12 '07 #192
Rainer Weikusat wrote:
>
CBFalconer <cb********@yahoo.comwrites:
[...]
My compilers exercise a random generator on each ++ (or --) call.
If two of them on the same object occur between sequence points it
uses the last random value to select a function to call. This can
be any function in any process, live or not (and requires system
specific code). This produces an amazing density of nasal demons.
Someday it may well launch WWIII. It is standard conforming.

This text would fit into a newsgroup whose topic is production of
mildly creative absurd fiction or one discussing quirks of a
particular implementation of C BUT NOT into a discussion of C, because
it is only insofar related to it as it talks about something the
C-standard does not talk about. And 'C' is the set of things the
C-standard DOES talk about.
We're talking about "undefined behavior", which is something that
the Standard purposely leaves _undefined_. This means that _any_
behavior is acceptable as far as the Standard is concerned.

This is not the case of a "quick of a particular implementation".
Rather, it is a specific counterexample to the false assertion
that "i = i++;" can only do one of two things -- leave "i" alone,
or increment it.
One would assume that this cannot be that complicated for someone
trying to understand it, ie someone whose motivation is not the very
production of mildly creative absurd fiction.
What is so complicated about understanding that these are used to
show that those false assertions above are, in fact, false? And, as
such, serve a very real purpose?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Sep 12 '07 #193
"Keith Thompson" <ks***@mib.orga crit dans le message de news:
ln************@nuthaus.mib.org...
Army1987 <ar******@NOSPAM.itwrites:
>On Tue, 11 Sep 2007 03:59:04 +0000, Richard Heathfield wrote:
>>No, they don't. Nature has no laws. Nature has behaviour. We observe
that behaviour, and formulate "laws" which explain it. Nature, however,
is under no obligation to observe those "laws" (and indeed frequently
breaks them). For example, the vast majority of gases don't observe the
gas laws.

<topicality level="LDBL_MIN">
They are approximate laws. There are laws which instead are
believed to be exact (e.g. the conservation of electrical charge).
So even if the Standard doesn't forbid

char *str = "Hey!";
size_t len = strlen(str);
struct flexible {
size_t size;
char data[1];
} *word = malloc(sizeof *word + len);
if (word != NULL) {
word->size = len;
strcpy(word->data, str);
puts(word->data);
}

from causing all electrons in my body to turn into positrons, I
am quite confident that this won't happen.

All the electrons in your body could turn into positrons without
violating the conservation of electrical charge, as long as an
appropriate number of negatively charged particles are also created.
Such as all protons in his body turning into antiprotons... Not a good time
to shake hands !

--
Chqrlie.
Sep 12 '07 #194
"Mark McIntyre" <ma**********@spamcop.neta crit dans le message de news:
lo********************************@4ax.com...
On Wed, 12 Sep 2007 11:45:48 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:
>>Army1987 <ar******@NOSPAM.itwrites:
>><topicality level="LDBL_MIN">
They are approximate laws. There are laws which instead are
believed to be exact (e.g. the conservation of electrical charge).
So even if the Standard doesn't forbid
...
>>from causing all electrons in my body to turn into positrons, I
am quite confident that this won't happen.

All the electrons in your body could turn into positrons without
violating the conservation of electrical charge,

Quite likely to violate conservation of mass, energy and momentum
tho...
>>as long as an
appropriate number of negatively charged particles are also created.

Fewer things are impossible than you might assume.

Technically, nothing is impossible since the universe is infinite in
some dimension or other.
I'm afraid that's impossible to prove.

--
Chqrlie.
Sep 12 '07 #195
Richard Tobin wrote:
CBFalconer <cb********@maineline.netwrote:
>>So that they can work wothout FILE being a complete type. You
said it had to be one so that getc() and putc() could be macros;
but that's not true because the definition of getc() could cast
the FILE * to, say, _FILE *, where _FILE is the complete type.
>But the only point of the macros is to access the internal
structure of the FILE object for such items as buffer usage
counters, etc. It also has to be able to call some routine to
refill the buffers when exhausted. The point of the macro is not
to have a macro, but to increase the system performance level.
_FILE knows nothing about these, and is thus useless.

_FILE would contain the real fields.

This is getting tedious, so here's a sketch of an extract from
stdio.h:

typedef struct FILE FILE;

typedef struct _FILE {
unsigned char *buf;
insigned char *pos;
int count;
...
} _FILE;

#define getc(f) (((_FILE *)(f))->count-- 0 ?
(int)*((_FILE *)(f))->pos++ :
getc(f))

It's just like it would be if FILE was the complete type, but
with casts to _FILE * everywhere.
And what makes you think that that _FILE description describes the
actual structure that exists for any arbitrary file? If it does,
it may well work. If not, it certainly won't.

However, the system implementor can limit the information he
publishes by:

#define getc(f) ((f)->count-- 0 ? *((f)->pos++) : (getc(f))

#define _FILEbuf .... /* the things used in getc or putc */

typedef struct FILE {_FILEbuf, _FILEstuff}

so that a pointer to a FILE is also a pointer to a _FILEbuf, but
the knowledge exposed is limited. Don't worry about syntax errors
above, I am just trying to pass on the general idea. The
definitions for _FILEstuff are elsewhere, and never user
accessible.

BTW, you have again deleted attributions for material you quoted.
Don't do that, some people also get highly annoyed at having their
words stolen without attribution.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Sep 13 '07 #196
kuyper <ku****@wizard.netwrites:
Rainer Weikusat wrote:
>This text would fit into a newsgroup whose topic is production of
mildly creative absurd fiction or one discussing quirks of a
particular implementation of C BUT NOT into a discussion of C, because
it is only insofar related to it as it talks about something the
C-standard does not talk about. And 'C' is the set of things the
C-standard DOES talk about.
[...]
But it is NOT pointless to illustrute what "undefined behavior"
means by giving extreme examples.
It is not possible to illustrate 'nothing' by providing examples of
it.
Sep 13 '07 #197

Rainer Weikusat wrote:
kuyper <ku****@wizard.netwrites:
Rainer Weikusat wrote:
This text would fit into a newsgroup whose topic is production of
mildly creative absurd fiction or one discussing quirks of a
particular implementation of C BUT NOT into a discussion of C, because
it is only insofar related to it as it talks about something the
C-standard does not talk about. And 'C' is the set of things the
C-standard DOES talk about.

[...]
But it is NOT pointless to illustrute what "undefined behavior"
means by giving extreme examples.

It is not possible to illustrate 'nothing' by providing examples of
it.
True, but not very relevant. "nothing" is only one of the possible
forms that undefined behavior can take, and the huge, infinite variety
of other forms that it can take can indeed be illustrated.
If you think that "nothing" is the only permitted form of undefined
behavior, then you have most severely incorrect understanding of the
term.

Sep 13 '07 #198
In article <46**************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>This is getting tedious, so here's a sketch of an extract from
stdio.h:

typedef struct FILE FILE;

typedef struct _FILE {
unsigned char *buf;
insigned char *pos;
int count;
...
} _FILE;

#define getc(f) (((_FILE *)(f))->count-- 0 ?
(int)*((_FILE *)(f))->pos++ :
getc(f))

It's just like it would be if FILE was the complete type, but
with casts to _FILE * everywhere.
>And what makes you think that that _FILE description describes the
actual structure that exists for any arbitrary file? If it does,
it may well work. If not, it certainly won't.
I'm describing a possible implementation. _FILE contains the correct
structure because the implementor decided it that way.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Sep 13 '07 #199
CBFalconer wrote:
Richard Tobin wrote:
....
_FILE would contain the real fields.

This is getting tedious, so here's a sketch of an extract from
stdio.h:

typedef struct FILE FILE;

typedef struct _FILE {
unsigned char *buf;
insigned char *pos;
int count;
...
} _FILE;

#define getc(f) (((_FILE *)(f))->count-- 0 ?
(int)*((_FILE *)(f))->pos++ :
getc(f))

It's just like it would be if FILE was the complete type, but
with casts to _FILE * everywhere.

And what makes you think that that _FILE description describes the
actual structure that exists for any arbitrary file? If it does,
it may well work. If not, it certainly won't.
Well, the statements "_FILE is the complete type" and "_FILE would
contain the real fields" seemed, in context, pretty clear statements
of the fact that the implementor would ensure precisely that. The
"_FILE" identifier is from the name space reserved for the
implementation, and it's described as being used in <stdio.h>. As you
say, if _FILE didn't describe the actual structure, those macros
wouldn't work; and they could therefore not be part of a conforming
implementation of the C standard library. It's clear from context that
this was intended to describe a conforming implementation, so the
implementator must make sure that _FILE does correctly describe that
actual structure.

Sep 13 '07 #200

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by Krumble Bunk | last post: by
27 posts views Thread by =?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?= | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.