Library bug or my fault?

[Richard Heathfield]

Re: Library bug or my fault?

jacob navia said:

Richard Heathfield wrote:

>jacob navia said:
>>

>>Chris Dollin wrote:
>>>OK, I admit it: not only does your implementation not do this,
>>>I don't have one that does either.
>>OK. We agree then.

>>
>Well, half-agree, anyway. You agree with your opinion, but he doesn't.
>>

>
It would be nice if you spoke for yourself.

I do so.

I do not speak for anyone else.

Then why did you misrepresent Chris's position?

Mr Dollin can say that for himeself

He did, but you tried to pretend he'd said something different.

>

>>There are no implementations that
>>use some unspecified bits to see if a variable was initialized or not.

>>
>That's not what he said. He said he doesn't have such an implementation.
>The fact that two, or three, or even a million people don't have pet
>aardvarks does not imply that nobody has a pet aardvark. Furthermore,
>even if it could somehow be shown that nobody has a pet aardvark today,
>that doesn't imply that nobody will have a pet aardvark tomorrow.

>
This rubbish is typical of your prose here.

Okay, so you don't understand it. Fine. And anything you don't understand,
you dismiss as rubbish, as I know only too well. So I'll try to explain it
in a completely different way.

The fact that two, or three, or even a million people don't have machines
that can have integer trap representations does not imply that nobody has
a machine that can have integer trap representations . Furthermore, even if
it could somehow be shown that nobody has a machine that can have integer
trap representations today, that doesn't imply that nobody will have a
machine that can have integer trap representations tomorrow.

Is that clearer? Or don't you understand that, either?

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Re: Library bug or my fault?

Richard Heathfield wrote:

The fact that two, or three, or even a million people don't have machines
that can have integer trap representations does not imply that nobody has
a machine that can have integer trap representations . Furthermore, even if
it could somehow be shown that nobody has a machine that can have integer
trap representations today, that doesn't imply that nobody will have a
machine that can have integer trap representations tomorrow.
>
Is that clearer? Or don't you understand that, either?
>

Of course I understand it:

"I can confuse everyone with bogus machines as long as I want to
because I do not need to have any relationship with reality. I can
*just invent* a possible machine with the characteristics I desire
so that I can go on confusing issues, making stupid assertions
about things that are legal or not, etc."

I understand it 100%. I just think that you are well, just
spraying nonsense (as most of the time)



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Randy Howard]

Re: Library bug or my fault?

On Tue, 22 Jul 2008 13:46:34 -0500, jacob navia wrote
(in article <g659vv$1e2$1@a ioe.org>):

Richard Heathfield wrote:

>The fact that two, or three, or even a million people don't have machines
>that can have integer trap representations does not imply that nobody has
>a machine that can have integer trap representations . Furthermore, even if
>it could somehow be shown that nobody has a machine that can have integer
>trap representations today, that doesn't imply that nobody will have a
>machine that can have integer trap representations tomorrow.
>>
>Is that clearer? Or don't you understand that, either?
>>

>
Of course I understand it:
>
"I can confuse everyone with bogus machines as long as I want to
because I do not need to have any relationship with reality. I can
*just invent* a possible machine with the characteristics I desire
so that I can go on confusing issues, making stupid assertions
about things that are legal or not, etc."
>
I understand it 100%. I just think that you are well, just
spraying nonsense (as most of the time)

Why do you spend so much time and energy trying to defend suspect code?
Is it just because you live and breathe for the chance to disagree
with "the evil regulars", or do you truly believe that analyzing the
contents of uninitialized variables is useful?


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Richard Heathfield]

Re: Library bug or my fault?

jacob navia said:

Richard Heathfield wrote:

>The fact that two, or three, or even a million people don't have
>machines that can have integer trap representations does not imply that
>nobody has a machine that can have integer trap representations .
>Furthermore, even if it could somehow be shown that nobody has a machine
>that can have integer trap representations today, that doesn't imply
>that nobody will have a machine that can have integer trap
>representation s tomorrow.
>>
>Is that clearer? Or don't you understand that, either?
>>

>
Of course I understand it:

I think you don't understand it...

>
"I can confuse everyone with bogus machines as long as I want to
because I do not need to have any relationship with reality.

....and now I know you don't understand it.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Re: Library bug or my fault?

Randy Howard said:

On Tue, 22 Jul 2008 13:46:34 -0500, jacob navia wrote

<snip>

>I understand it 100%. I just think that you are well, just
>spraying nonsense (as most of the time)

>
Why do you spend so much time and energy trying to defend suspect code?

Vendor lock-in.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[dj3vande@csclub.uwaterloo.ca.invalid]

Re: Library bug or my fault?

In article <g64vae$dev$1@r egistered.motza rella.org>,
Richard <rgrdev@gmail.c omwrote:

>But meanwhile in the real world where efficiency and cost effective SW
>development is important ...

....portability matters.

At my day job, we have both code written by standards-and-portability
weenies and code written by whatever-works types.

In terms of efficiency of the code, the standards-and-portability
weenies have a very slight advantage, since they fix their bugs
*before* the optimizer makes subtle bugs less subtle. But that's
barely noticeable at the best of times, and only a small amount of code
actually *needs* to run fast.

In terms of cost-effective development, any difference in productivity
between the standards-and-portability types and the whatever-works
types is completely lost in the effects of understanding of the problem
domain. (We have a lot of variability in the latter (in both the
problem domains and in who understands which ones how well), and it's
pretty much completely independent of the attitudes toward
portability.)


So for single-platform development, there's no detectable difference.
But now we're thinking of switching platforms.

The standards-and-portability weenies have already tested half the code
they've written on the platform we're thinking of switching to, since
that's what standards-and-portability weenies do. (Besides, some types
of problem are a lot easier to debug on that platform than on the one
we currently deploy on, so being able to run the code there already has
a nonnegative ROI.)
The whatever-works types have a whole bunch of code that has never been
compiled or run outside our current toolchain and deployment platform.

Which chunks of code do you think we're more likely to be able to get
running efficiently and cost-effectively on the new platform?


dave
(I don't expect Richard to provide any evidence of having gotten my
point, but it's worth pointing out for other readers.)

--
Dave Vandervies dj3vande at eskimo dot com
I have to go through 37 more source files of the original programmer.
He may well receive (posthumously) my thanks for making me a better
C programmer. --Nishad Prakash in comp.lang.c

[jacob navia]

Re: Library bug or my fault?

Keith Thompson wrote:

>
Consider a hypothetical implementation with the following
characteristics :
>
CHAR_BIT == 8
sizeof(int) == 4 (32 bits)
INT_MIN == -8388608 (-2**23)
INT_MAX == +8388607 (+2**23-1)
>
Type int has 1 sign bit, 23 value bits, and 8 padding bits.
>
Storing the result of evaluating any arithmetic expression in an int
object causes the object's padding bits to be set to zero. (This can
be verified by interpreting the object's representation as an array of
unsigned char.) Evaluating the value of an object with non-zero
padding bits causes immediate termination of the program.
>

Such a system is possible... if you do not care about
practical considerations. ..

I know of no actual system that has the above characteristics ; that's
not the point. I do not claim that such a system is likely to be
built in the future; that's not the point either (though there could
be legitimate reasons, reasons I haven't thought of, to build such a
system). The point is that such a system conforms to the C standard,
and there *could* be some future system that does exhibit the
characteristics I've described.
>

Yes. Something like that *could* exist.

Do you agree?

Yes.

If so, doesn't that contradict your statement about
padding bits being "masked by the hardware"?

You are not talking about padding bits. You are talking about
control bits that are similar to the parity bits in serial
transmissions. Padding bits exist for alignment reasons.
Parity/control bits/redundancy bits are not there just to take
space, they have redundancy objectives.

If you don't agree, why
not?
>

See above

I understand that you personally dislike the "regulars", of whom I am
one; as you wrote in another thread, "I am completely opposed to that
people". In replying to this, please try to get past your personal
animosity and respond to what I actually wrote.
>

I did, but it was quite an effort. Anyway discussions are quite
useless. What bothers me here is that in discussions of people
that ask simple questions, regulars *invent* machines that
*could* exist just to confuse people.

They like (as all pedants) displaying their great "C knowledge",
by inventing possible situations where this or that paragraph of
the standard could apply.

As a matter of fact (of course) they are AGAINST the C99 standard
that they try to disqualify at each post. But they pose as
if they were for Standard C.

That is the AS IF rule!


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Keith Thompson]

Re: Library bug or my fault?

jacob navia <jacob@nospam.c omwrites:

Keith Thompson wrote:

>Consider a hypothetical implementation with the following
>characteristic s:
> CHAR_BIT == 8
> sizeof(int) == 4 (32 bits)
> INT_MIN == -8388608 (-2**23)
> INT_MAX == +8388607 (+2**23-1)
>Type int has 1 sign bit, 23 value bits, and 8 padding bits.
>Storing the result of evaluating any arithmetic expression in an int
>object causes the object's padding bits to be set to zero. (This can
>be verified by interpreting the object's representation as an array of
>unsigned char.) Evaluating the value of an object with non-zero
>padding bits causes immediate termination of the program.

>
Such a system is possible... if you do not care about
practical considerations. ..

As a practical consideration, it's possible that some future system,
or perhaps some relatively exotic system that already exists that
neither of us happens to be familiar with, could have exactly the
characteristics I mentioned above, or something very similar.

I think I may actually have worked on a system that has padding bits
in some integer types. I didn't happen to do anything that was
affected by this, and I didn't check the values from <limits.hwhil e
I still had access to the system, so I can't be sure. The system was
a Cray T90; I'm fairly sure that it or some of its predecessors used
something like 24 out of 64 bits for some integer types. If I can get
access to a Cray again, I'll check it out.

The T90 is admittedly a fairly old system, and there are probably only
a few of them still in service. But they're not *that* old; the first
were shipped in 1995. And the reason for the odd behavior was a very
strong emphasis on floating-point over integer arithmetic, something
that could very well be a decisive factor for some future systems.

In any case, I actually find it *easier* in most cases to write code
that depends only on what's guaranteed by the standard.

>I know of no actual system that has the above characteristics ; that's
>not the point. I do not claim that such a system is likely to be
>built in the future; that's not the point either (though there could
>be legitimate reasons, reasons I haven't thought of, to build such a
>system). The point is that such a system conforms to the C standard,
>and there *could* be some future system that does exhibit the
>characteristic s I've described.

>
Yes. Something like that *could* exist.
>

>Do you agree?

>
Yes.

Excellent.

>If so, doesn't that contradict your statement about
>padding bits being "masked by the hardware"?

>
You are not talking about padding bits. You are talking about
control bits that are similar to the parity bits in serial
transmissions. Padding bits exist for alignment reasons.
Parity/control bits/redundancy bits are not there just to take
space, they have redundancy objectives.

Yes, I certainly am talking about padding bits. I asked you to read
C99 6.2.6.2. Please read it again. It explains quite clearly what
padding bits are.

To be clear, parity bits that aren't visible to software are not
padding bits. Padding bits, as defined by the standard, exist only
for integer types; they're bits that are part of the type's
representation (and can therefore be seen if you view the type as an
array of unsigned char) but do not contribute to its value.

Padding *bytes* are used for alignment in structures; they're
mentioned in C99 6.2.6.1.

>If you don't agree, why
>not?

>
See above
>

>I understand that you personally dislike the "regulars", of whom I am
>one; as you wrote in another thread, "I am completely opposed to that
>people". In replying to this, please try to get past your personal
>animosity and respond to what I actually wrote.

>
I did, but it was quite an effort.

It should become easier with practice. Seriously.

Anyway discussions are quite
useless. What bothers me here is that in discussions of people
that ask simple questions, regulars *invent* machines that
*could* exist just to confuse people.

No, we invent machines that could exist to illustrate the wide variety
of machines that are possible, and to encourage programmers to think
about portability when they write code.

They like (as all pedants) displaying their great "C knowledge",
by inventing possible situations where this or that paragraph of
the standard could apply.
>
As a matter of fact (of course) they are AGAINST the C99 standard
that they try to disqualify at each post. But they pose as
if they were for Standard C.

I am not against the C99 standard. Where have I said that I am?

That is the AS IF rule!

No, it isn't.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Re: Library bug or my fault?

jacob navia said:

Keith Thompson wrote:

>>
>Consider a hypothetical implementation with the following
>characteristic s:
>>
> CHAR_BIT == 8
> sizeof(int) == 4 (32 bits)
> INT_MIN == -8388608 (-2**23)
> INT_MAX == +8388607 (+2**23-1)
>>
>Type int has 1 sign bit, 23 value bits, and 8 padding bits.
>>
>Storing the result of evaluating any arithmetic expression in an int
>object causes the object's padding bits to be set to zero. (This can
>be verified by interpreting the object's representation as an array of
>unsigned char.) Evaluating the value of an object with non-zero
>padding bits causes immediate termination of the program.
>>

>
Such a system is possible... if you do not care about
practical considerations. ..

I certainly hope that nobody would ever design such a system by choice, so
presumably such a system would only ever be designed *because* of
practical considerations.

Oops, I nearly gave another picturesque analogy. A good one, too. But
what's the point?

<snip>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Peter Nilsson]

Re: Library bug or my fault?

Nick Keighley wrote:

Peter Nilsson <ai...@acay.com .auwrote:

Steven Woody wrote:

The problem is, the line 38 which copy 3 bytes, starting from
p2, to p1, but the immediately followed memcmp (line 42)
shows the memcpy was not well done.

It's the lines before that signal a problem.

------------------------------------- the minimum sample
--------------------------------------------------
1 #include <stdio.h>
2 #include <string>
3 #include <stdint.h>
4 #include <assert.h>
5
6 struct Foo {
7 � � uint8_t x;
8 � � uint8_t y;
9 � � uint8_t z;
10 � � uint8_t m[3];
11 };
12
13 struct Bar
14 {
15 � � uint8_t m[3];
16 };

These are completely different structs.

>
yes, so?

So conversion of an address of one (not the first) struct member
into a pointer to another struct is already suspicious.

29 void cp(const Foo *foo)
30 {
31 � � Bar bar;
32
33 � � Bar *p1 = &bar;
34 � � Bar *p2 = (Bar*)(foo->m);

The fact you have a cast to silence a warning (or more likely
error) on incompatible types is the problem. Bar is not an array,
it is a struct containing an array.

>
yes, but there can't be padding at the beginning of a struct

Irrelevant. The m being copied is in the middle of a Foo. Given
that it isn't a Bar, why should a pointer to that be portably
convertable to a pointer to Bar?

hence Bar.m and Bar must be at the same address.

As my suggestion went on to show, there is clearly no problem
copying an array to an array of the same type and size directly.
But for no obvious reason, the code avoids that simple course.

Also uint8_t is probably (almost certainly) an alias (typedef)
for unsigned char and you can safely cast *anything* to
unsigned char

Again, irrelevant. There is no conversion to unsigned char
anywhere in the code quoted above.

I'd say this pretty well had to work (do you have a compiler where
it doesn't work?)

The OP has a compiler where the code doesn't work. I don't know
why the compiler's doing what it's doing, I merely know that, on the
basis of what's been posted, neither the compiler nor the library
can be said to be at fault.

The standard allows the conversion (if foo->m is aligned
properly),

>
why would foo->m not be correctly aligned?

Because any struct can have alignment requirements that are stricter
than the elements it contains.

Can you state any reasons why an implementation couldn't pad
a 3 byte structure to 4 bytes size and alignment?

--
Peter

[Barry Schwarz]

Re: Library bug or my fault?

On Mon, 21 Jul 2008 23:46:07 -0700 (PDT), Steven Woody
<narkewoody@gma il.comwrote:

>Hi,
>
>Please check the sample code listed in the end of the message. It was
>compiled using ARM/Linux cross-compiler and run on an ARM9 target. I
>think the problem applies to this group because two cross-compiler
>from different vendor result same error. So I guess it is not vendor
>specific. If my guess is right, then it means the code itself may get
>problem, but I can not figure out where it is.
>
>The problem is, the line 38 which copy 3 bytes, starting from p2, to
>p1, but the immediately followed memcmp (line 42) shows the memcpy was
>not well done. I am sure the memcpy did not do the job, since if I
>provide my own memcpy implemention as below, the error will go
>disappear.
>
>void memcpy(void *dest, void *src, size_t n)
>{
uint8_t *d = (uint8_t*)dest;

Why do you have a cast here?

uint8_t *s = (uint8_t*)src;
>
for (size_t i = 0; i < n; ++i)

What is the guarantee that n is never larger that sizeof(uint8_t) ?

*d++ = *s++;
>}
>
>Could you please check the code as well as the running result and
>tell me what wrong with it? Thanks.
>
>
>------------------------------------- the minimum sample
>--------------------------------------------------
>1 #include <stdio.h>
>2 #include <string>

You need to post your real code using cut and paste. Retyping just
introduces other errors confusing everyone.

>3 #include <stdint.h>
>4 #include <assert.h>
>5
>6 struct Foo {
>7 uint8_t x;
>8 uint8_t y;
>9 uint8_t z;
>10 uint8_t m[3];
>11 };
>12
>13 struct Bar
>14 {
>15 uint8_t m[3];
>16 };
>17
>18 void pr(const char *title, const void *block, size_t n)
>19 {
>20 printf("%s\n", title);
>21
>22 uint8_t *p = (uint8_t*)block ;

This cast removes the const attribute. You should add it back by
fixing the definition of p. Otherwise, there is no point in having in
the function definition at all.

>23 for (size_t i = 0; i < n; ++i)
>24 printf("0x%02x ", *p++);
>25
>26 printf("\n");
>27 }
>28
>29 void cp(const Foo *foo)
>30 {
>31 Bar bar;
>32
>33 Bar *p1 = &bar;
>34 Bar *p2 = (Bar*)(foo->m);
>35 pr("before: p1:", p1, 3);
>36 pr("before: p2:", p2, 3);
>37
>38 memcpy(p1, p2, 3);
>39 pr("after: p1:", p1, 3);
>40 pr("after: p2:", p2, 3);
>41
>42 if (memcmp(p1, p2, 3) != 0)
>43 printf("!!! cp is wrong\n");

After making the obvious tweaks for C89, the code ran exactly as
expected on my system and never printed this message. By any chance
does your actual code have a ; after the if?

>44 }
>45
>46 int main()
>47 {
>48 Foo foo;
>49 foo.x = 1;
>50 foo.y = 2;
>51 foo.z = 3;
>52 foo.m[0] = 0x40;
>53 foo.m[1] = 0x19;
>54 foo.m[2] = 0x21;
>55
>56 cp(&foo);
>57 cp2(&foo);
>58 return 0;
>59 }
>------------------------------------------------------------------
>
>Below is the running output on an ARM920T board:
>
>before: p1:
>0xfc 0x01 0x12
>before: p2:
>0x40 0x19 0x21
>after: p1:
>0x40 0x01 0x02
>after: p2:
>0x40 0x19 0x21
>!!! cp is wrong

Remove del for email

[Dik T. Winter]

Re: Library bug or my fault?

In article <lnvdyxik6i.fsf @nuthaus.mib.or gKeith Thompson <kst-u@mib.orgwrites :
....

I think I may actually have worked on a system that has padding bits
in some integer types. I didn't happen to do anything that was
affected by this, and I didn't check the values from <limits.hwhil e
I still had access to the system, so I can't be sure. The system was
a Cray T90; I'm fairly sure that it or some of its predecessors used
something like 24 out of 64 bits for some integer types. If I can get
access to a Cray again, I'll check it out.

24 bits was used for 'short' and as a compiler option for 'int'. But
'int' itself was only 48 bits out of 64. And if the upper 16 bits were
not all zero you could get a big surprise when multiplying such things.

(When not all 16 bits of both operands were zero the multiplying unit
would assume that the operands were floating point and operate
accordingly.)
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Keith Thompson]

Re: Library bug or my fault?

"Dik T. Winter" <Dik.Winter@cwi .nlwrites:

In article <lnvdyxik6i.fsf @nuthaus.mib.or gKeith Thompson
<kst-u@mib.orgwrites :
...

I think I may actually have worked on a system that has padding bits
in some integer types. I didn't happen to do anything that was
affected by this, and I didn't check the values from <limits.hwhil e
I still had access to the system, so I can't be sure. The system was
a Cray T90; I'm fairly sure that it or some of its predecessors used
something like 24 out of 64 bits for some integer types. If I can get
access to a Cray again, I'll check it out.

>
24 bits was used for 'short' and as a compiler option for 'int'. But
'int' itself was only 48 bits out of 64. And if the upper 16 bits were
not all zero you could get a big surprise when multiplying such things.
>
(When not all 16 bits of both operands were zero the multiplying unit
would assume that the operands were floating point and operate
accordingly.)

Thanks.

There was never a C99 compiler for the Cray T90, and the concepts of
"padding bits" and "trap representations " were introduced by C99.

However, we have demonstrated by example a fairly recent system (still
in production use within the last 10 years) on which integer types can
have bits that don't contribute to the value, but which are not
ignored, resulting in incorrect results if those bits take on certain
values. This admittedly odd design was not implemented for the fun of
it; it was done for perfectly valid reasons.

And it's entirely plausible that something similar could show up in a
future design.

jacob would have us pretend that this just isn't possible. It's
basically the same thing as the old "All the world's a VAX" syndrome,
or its modern equivalent the "All the world's an x86" syndrome.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Antoninus Twink]

Re: Library bug or my fault?

On 22 Jul 2008 at 16:57, Ike Naar wrote:

In article <g651bq$mus$1@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:

>>But since you can't point me to ANY such machine now, I strongly
>>suspect that when discussing problems in C programming TODAY we should
>>NOT confuse everyone with obsolete machines.

>
My only point was to illustrate that machines, that you claimed only exist
"in the minds of the regulars" exist elsewhere too.

It's really very simple. If someone has a question about programming in
C on a mainframe from the stone-age with trap representations and the
like, or if they're programming an embedded system with 16-bit chars and
half the standard library missing, then all they have to do is make that
clear from the beginning, and then that will be the context for that
thread.

Otherwise, doesn't it make sense to work on the assumption that they're
part of the 99.9% of the world using a modern operating system on modern
hardware? Anywhere apart from in the autistic heart of clc that wouldn't
be controversial in the slightest, merely basic common sense.

[jacob navia]

Re: Library bug or my fault?

Antoninus Twink wrote:

On 22 Jul 2008 at 16:57, Ike Naar wrote:

>In article <g651bq$mus$1@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:

>>But since you can't point me to ANY such machine now, I strongly
>>suspect that when discussing problems in C programming TODAY we should
>>NOT confuse everyone with obsolete machines.

>My only point was to illustrate that machines, that you claimed only exist
>"in the minds of the regulars" exist elsewhere too.

>
It's really very simple. If someone has a question about programming in
C on a mainframe from the stone-age with trap representations and the
like, or if they're programming an embedded system with 16-bit chars and
half the standard library missing, then all they have to do is make that
clear from the beginning, and then that will be the context for that
thread.
>
Otherwise, doesn't it make sense to work on the assumption that they're
part of the 99.9% of the world using a modern operating system on modern
hardware? Anywhere apart from in the autistic heart of clc that wouldn't
be controversial in the slightest, merely basic common sense.
>

Please do not speak about "common sense" here. It is not mentioned
in the C standard of 1989.



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32