473,320 Members | 1,854 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

C89, size_t, and long

Hey,

I was reading C99 Rationale, and it has the following two QUIET CHANGE
paragraphs:

6.5.3.4: "With the introduction of the long long and extended integer
types, the sizeof operator may yield a value that exceeds the range
of an unsigned long."

6.5.6: "With the introduction of the long long and extended integer
types, the subtraction of pointers may return a value that exceeds the
range of a long."

Was it required by C89 that result of sizeof() fits into unsigned long,
and that pointer subtraction result fits into long? If yes, then MS
Win64 implementation is not C89-conforming (while sizeof case may be
arguable, I guess, we certainly can ask to malloc more than ULONG_MAX
bytes, and get pointer arithmetics which needs more than (unsigned)
long). If no, why these two paragraphs, if programs which relied on long
being big enough were already broken?

Yevgen
Mar 14 '07
73 7303
Flash Gordon wrote:
Keith Thompson wrote, On 16/03/07 23:33:
>Flash Gordon <sp**@flash-gordon.me.ukwrites:
[...]
>>Suggesting that they are avoiding the standard headers because they
think some implementation has headers broken enough that they have to
be avoided does suggest they are incompetent. However, elsewhere you
have admitted that it is glibc and looking at the headers in some of
them they *do* include stdef.h and stdio.h, so that obviously is *not*
the reason.

<OT>
I think he said he's talking about glib, not glibc. glib and glibc
are two different things. glibc is the GNU implementation of the
standard C library. glib is "the low-level core library that forms
the basis of GTK+ and GNOME".
</OT>

I know that, I intended to type glib, my saying glibc was a trypo. glib
*does* include stdef.h, stdio.h and string.h (maybe others) from within
its headers.
Could you provide an example of string.h and stdio.h?

Yevgen
Mar 17 '07 #51
Yevgen Muntyan <mu****************@tamu.eduwrites:
[...]
Of course it's not, since gnulib is intended to be a complement to
any-C-library.
Gnulib? I thought you were talking about glib. Or are you talking
about both?

Just to make sure everyone is clear on this (and not necessarily to
imply that anyone isn't), "gnulib", "glib", and "glibc" are three
different things.

Gnulib is the GNU portability library,
<http://www.gnu.org/software/gnulib/>.

glib is "the low-level core library that forms the basis of GTK+ and
GNOME", <http://www.gtk.org/>.

glibc is the GNU implementation of the standard C library,
<http://www.gnu.org/software/libc/>.

--
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"
Mar 17 '07 #52
Keith Thompson wrote:
Yevgen Muntyan <mu****************@tamu.eduwrites:
[...]
>Of course it's not, since gnulib is intended to be a complement to
any-C-library.

Gnulib? I thought you were talking about glib. Or are you talking
about both?
Both. glib is the evil library, gnulib is an example of how people work
around C implementation bugs.
Just to make sure everyone is clear on this (and not necessarily to
imply that anyone isn't), "gnulib", "glib", and "glibc" are three
different things.

Gnulib is the GNU portability library,
<http://www.gnu.org/software/gnulib/>.

glib is "the low-level core library that forms the basis of GTK+ and
GNOME", <http://www.gtk.org/>.

glibc is the GNU implementation of the standard C library,
<http://www.gnu.org/software/libc/>.
Yes.
Mar 17 '07 #53
Dave Vandervies wrote:
Flash Gordon <sp**@flash-gordon.me.ukwrote:
>I've never had to include a header just to get size_t when I
wanted it because I've somehow always without thinking included
a header (or more than one) that provides it.

I can make a stronger statement than that: I've started writing
code, decided I wanted to use a size_t, and therefore added (or
made a mental note to add) a "#include <stddef.h>"... But every
time, I've ended up (often as the next thing I do) adding a call
to a standard library function declared in a header that defines
size_t anyways. So I've never had a reason to #include <stddef.h>
by the time I let a compiler see the code.
The fact that size_t is defined in various headers is incidental.
The point is that the routines in <arbitrary.hrequire size_t to
be defined, so that is done. Otherwise there would be awkward
dependencies between header files.

--
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

Mar 17 '07 #54
Yevgen Muntyan wrote:
Flash Gordon wrote:
>Yevgen Muntyan wrote, On 16/03/07 22:46:
>>Flash Gordon wrote:
Yevgen Muntyan wrote, On 16/03/07 18:49:
Flash Gordon wrote:
>Yevgen Muntyan wrote, On 16/03/07 15:26:
>>Flash Gordon wrote:
>>>Yevgen Muntyan wrote, On 16/03/07 06:22:
[snip]
This thread has received a well-deserved PLONK here.

--
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

Mar 17 '07 #55
CBFalconer wrote:
Yevgen Muntyan wrote:
>Flash Gordon wrote:
>>Yevgen Muntyan wrote, On 16/03/07 22:46:
Flash Gordon wrote:
Yevgen Muntyan wrote, On 16/03/07 18:49:
>Flash Gordon wrote:
>>Yevgen Muntyan wrote, On 16/03/07 15:26:
>>>Flash Gordon wrote:
>>>>Yevgen Muntyan wrote, On 16/03/07 06:22:
[snip]

This thread has received a well-deserved PLONK here.
I'm glad there will be less valuable comments by Chuck
about who's idiot and who isn't.
Mar 17 '07 #56
Yevgen Muntyan said:

<snip>
I didn't understand you mean "attacking Mr.
Heathfield". Well, he came accusing me of calling him a liar, and
did not present any evidence of that. Ask him when I called him a
liar.
"[...] you're either lying or you do as you usually do - posts where
every letter is correct but post as whole doesn't carry any useful
information." - Yevgen Muntyan.

Both charges are false, of course, but insofar as Mr Muntyan considers
either of them to be true, I currently see no value in providing
further responses to any of his questions about C.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 17 '07 #57
Richard Heathfield wrote:
Yevgen Muntyan said:

<snip>
>I didn't understand you mean "attacking Mr.
Heathfield". Well, he came accusing me of calling him a liar, and
did not present any evidence of that. Ask him when I called him a
liar.

"[...] you're either lying or you do as you usually do - posts where
every letter is correct but post as whole doesn't carry any useful
information." - Yevgen Muntyan.
Surely without context. Of course, you don't want to bring that in.
It's better just to complain about me calling you a liar. Oh
this terrible word "lie"! Mr. Heathfield is totally fine with insulting
others two times a day (twenty in good days), but now someone
has some doubts about Holy Reasons for insulting people or
posting to post a post with "Try to find a mistake here you can't".
Both charges are false, of course, but insofar as Mr Muntyan considers
either of them to be true,
You said I called you a liar. So, I believe you took both or the first
one as true. Well, to make it clear, in that context, if I recall
correctly, you lied to my best understanding. The second "charge"
was an exaggeration, you don't usually post those things. They are
just about half of your posts.
I currently see no value in providing
further responses to any of his questions about C.
You already said you are not going to reply at all.
It's sad to lose such a nice source of information as this newsgroup,
but perhaps it's better if I don't read pearls by nice fluffy Richard.
Mar 17 '07 #58
CBFalconer wrote:
Dave Vandervies wrote:
Flash Gordon <sp**@flash-gordon.me.ukwrote:
I've never had to include a header just to get size_t when I
wanted it because I've somehow always without thinking included
a header (or more than one) that provides it.
I can make a stronger statement than that: I've started writing
code, decided I wanted to use a size_t, and therefore added (or
made a mental note to add) a "#include <stddef.h>"... But every
time, I've ended up (often as the next thing I do) adding a call
to a standard library function declared in a header that defines
size_t anyways. So I've never had a reason to #include <stddef.h>
by the time I let a compiler see the code.

The fact that size_t is defined in various headers is incidental.
The point is that the routines in <arbitrary.hrequire size_t to
be defined, so that is done. Otherwise there would be awkward
dependencies between header files.
Not really. The standard library functions can declare malloc's
parameter, strlen's result, etc. as whatever type size_t is a typedef
for, or if that type differs for multiple configurations of the same
implementation, it can use a __size_t type.

Mar 17 '07 #59
Yevgen Muntyan wrote, On 17/03/07 01:20:
Flash Gordon wrote:
>Yevgen Muntyan wrote, On 16/03/07 22:46:
>>Flash Gordon wrote:
Yevgen Muntyan wrote, On 16/03/07 18:49:
Flash Gordon wrote:
>Yevgen Muntyan wrote, On 16/03/07 15:26:
>>Flash Gordon wrote:
>>>Yevgen Muntyan wrote, On 16/03/07 06:22:
[snip]
>>>>>>>>Hm, somehow I don't believe you're most offended by me calling you
>>>>a liar. For some reasons I think the worst thing is disagreement
>>>>with you even after you present all your killer
>>>>100%-correct-and-ignore-everything-else arguments. Did I just
>>>>call you a
>>>>liar again?
>>>>Sorry about that, I do understand I will be hurt by this more
>>>>than you.
>>>>
>>>Whether Richard and Eric feel offended or hurt does not change
>>>whether it is an offensive thing to say.
>>>
>>So it's fine for Eric to insult other people by calling them
>>incompetent, but it was so bad from me to say an offensive thing?
>>
>The evidence you present suggests that they are incompetent.
>
Bullshit.

Suggesting that they are avoiding the standard headers because they
think some implementation has headers broken enough that they have
to be avoided does suggest they are incompetent.

I did *not* say glib avoids using standard headers. It does not, in
fact. It does avoid string.h,

It does not. At least, not in the version installed on this machine.
markg@brenda:/usr/include/glib-2.0/gobject$ grep string.h *
gobjectnotifyqueue.c:#include <string.h/* memset */

Um, so you did not understand I was talking about standard headers
in *headers*?
It's not my fault if they put a .c file in the includes directory which
is specifically for include files hence the name include. Since they
include header guards (again in a way that invades the implementation
name space) there is a strong suggestion that they expect people to
include it. As does the fact that it is only providing static functions,
typedefs, and struct definitions. Therefore I believe it *is* a header
file, it just does not have the conventional name.
If you really thought I was talking about library
sources, I apologize, and I must admit all I said seemed like
hundred times more stupid than I thought it did. Of course I meant
headers. Why do you think I was talking about that _GNU_SOURCE thing?
Because some glib source file is using it? Just to be clear,

#include <glib.h>

won't make declaration of strlen() visible. But size_t will be
defined.
No, but #include <gobjectnotifyqueue.cwill, and if you actually loot
at it you will see that is its intended use.
> but it doesn't avoid stddef.h. If you
think otherwise, please quote where I said glib uses unsigned long
instead of size_t because of headers thing.
Glib uses unsigned long there because of other reasons, which I
suspect are really "historic reasons". You and Eric easily jump
into "glib developers are incompetent". This is what I call bullshit,
or, politely, groundless, not honest and hostile.

You kept going on about knowing a library that did not use use size_t.
You also kept going on about how one reason for avoiding it could be
to avoid broken standard headers. If the two are unrelated then fine I
misread you.

However, there is still no reason to avoid the use of standard headers.

Some of the things in glib suggest trying to deal with pre-ANSI C, for
example defining NULL if it is not defined. Either that or it shows a
stupid (in my opinion) lack of trust in the standard libraries. The
same applies to the provision of an equivalent of the standard
offsetof macro.
There is also invasion of the implementations name space with struct
_GSource etc.

So yes, there is certainly some grounds to say that the author(s) do
not know C properly.

Yeah, sure. Especially the last thing, about underscore-prefixed
identifiers. "Some grounds", huh? Indeed, some grounds. Now can
you say it in plain text, "glib developers are incompetent"?
Mumbling "some ground" surely helps not to lose face and still
make yourself right. Please make the claim you seem to be defending.
I require a lot more investigation or discussion with the developers to
state categorically that they are incompetent, but as I say the evidence
points to significant holes in their knowledge.
>Oh, and one comment I found particularly amusing. 'These are useful
because a "gint8" can be adjusted to be 1 byte (8 bits) on all
platforms.' Ignoring the terminology problem, if char is not 8 bits
you are stuffed in terms of finding an 8 bit type!

You surely know that char is not signed char,
Yes, I know that. However, no typedef will allow you to provide an 8 bit
type is one does not exist and if char is not 8 bits one does not exist.
If, as you suggest, there reason is due to variability in the signedness
of plain char then one would expect them to state this and possibly
actually use signed char, since otherwise using a common option on gcc
on linux platforms will stop the typedef doing what they want.

I.e. that comment is still highly amusing to me for the lack of
knowledge it shows.
I have no doubts about
that. You think these folks use "gint" because they think int may not
be available?
No, they state a reason for that and it is a valid reason. Hence my not
saying it was a bad reason. Just because I criticise one thing does not
mean I am criticising everything.
However bad wording is (can't talk about it, it's not
my language), it means that gint8 plays the role of int8_t, but
If so then it is a broken definition for Linux systems using gcc which
is one of the primary targets.
in human-understandable language and without mentioning platforms
where char is not 8 bit (and the library won't work).
There is nothing wrong with the library not working on systems where
char is not 8 bit, but the reason given for gchar is just plain stupid
and the definition does not serve what *you* guess its purpose is.
--
Flash Gordon
Mar 17 '07 #60
Yevgen Muntyan wrote, On 17/03/07 00:04:
Flash Gordon wrote:
>Yevgen Muntyan wrote, On 16/03/07 16:12:
>>Flash Gordon wrote:
Yevgen Muntyan wrote, On 16/03/07 03:57:
...
> You know, if I am accused of asking standard to
bless using UB (read the thread if you like), then I can be said to fly
to Mars and whatnot. And then what?

I did not comment on that part of the argument because I did not want
to trace it back.

Right... You commented on parts you liked,
I comment on those things I decide to comment on and not on those things
I decide not to comment on. You and everyone else does exactly the same.
and you don't care about
the discussion in whole, where I say one thing and other hears what
he wants to hear. Just like here, you're saying I am claiming there
is a reason not to use standard headers. While I said like five times
that I do *not* know such a reason. Of course, from my unwillingness
to make baseless conclusions you make a conclusion that my opinion
is the contrary. And so on.
You sited what you thought might be a reason and seemed not to accept
that it was an exceedingly bad reason. You still seem not to accept that.
>>But you folks decided I am defending this particular thing, and
to justify that I accuse standard of causing all my problems. It
surely is easier to argue with.

The thing that got me was you appearing to be claiming that an
implementation with broken headers was a good reason to avoid
including them and therefore not having size_t available.

It was a hypothetical good reason for not using standard headers
in general,
I strongly disagree with the word "good" above. It would be an
incredibly bad reason.
which naturally leads to avoiding #includ'ing stddef.h.
But yes, I do support the following: if an implementation has broken
header foobar.h and I write code for that platform, I will try to work
it around; and if not using foobar.h is a fix, I will avoid using
foobar.h. And *no*, I do not avoid using standard headers in *my*
code because of hypothetical problems.
I am saying that if you came across the problem you should take EXACTLY
the attitude I have taken for some library versions and OSs and tell
people it is broken and that if they want to use your code they cannot
use that version of that library.

Since it works for a small company being paid to develop code for far
larger companies I don't see any reason it would not work in other
situations. It has also worked for one developer within a small company
writing code for far larger companies.
>>>I think you have it backwards. If you are claiming there is a reason
to avoid the mechanisms the standard provides to allow portability
then it is up to *you* to prove your point, not up to others to
disprove it.

I am claiming this: my (and yours, and Eric's, and all the regulars
here) lack of knowledge about one particular obscure system does
*not* imply I (you, Eric, etc.) *know* something about it. If
I write code, I don't worry about those obscure systems. But I
admit a possibility of someone who does worry about obscure system
I never heard about. I do *not* claim existence of that system.
Not sure what I need to prove here.

The point of using the facilities provided by the standard headers is
so that you do not have to worry about obscure systems since the
implementer has done the worrying for you.

Indeed, that's why we should use standard headers. And? Was it
you agreed or disagreed with my words about making conclusion
without having enough ground?
Writing code to deal with obscure systems is common, writing code to
deal with broken system libraries is at least extremely unusual.
>>>>>>>Every module that
>>>performs I/O includes <stdio.hand has size_t defined;
>>>
>>Unless this module use third-party I/O routines, or uses things like
>>open/write. I.e. no, not every.
>>
> Yes, "every"
>
Good you used "quotes" here.

Probably for emphasis.

I doubt it. Read the sentence. "Every module that performs I/O includes
<stdio.h>". It is not true. "Every" was put in quotes to make it "true".

I've never had to include a header just to get size_t when I wanted
it because I've somehow always without thinking included a header
(or more than one) that provides it.

Same thing. I rarely use size_t in fact. I did though have modules
which perform I/O and do not use stdio.h.

So you are using things outside of standard C. Now what would be
broken if you included one of the standard headers?

If *I* did, nothing would break. You can prove there are no weird things
in stdio.h like that strndup on every system? You can prove silent
#includ'ing stdio.h will not break user code?
Providing stndup is *not* a weird anomaly. It is a reserved name so the
library can use it for whatever purpose it wants without breaking
correct code.

If it claims conformance to the C standard then you know it does not.
That is the POINT of having a standard.
>>>>>-- unless you've decided to stray outside the
>bounds of Standard C. There are good reasons for such strayings,
>but you can hardly blame the consequences on the Standard headers.
>
If the headers in particular implementation are broken, then
they are broken. I don't blame the Standard for that. Not sure
if I blame "Standard headers". And not sure how it is relevant
to whether I use or do not use POSIX read and write.

Yet you are using broken headers and headers providing extensions
(all your examples being ones the standard allows them to do that
will not break any otherwise correct code) as a reason for not
including them. Broken headers is not a good reason to not use them
since if you cannot rely on the C implementation you cannot rely on
it and need to use a different one instead.

This is a very wrong thing. There may be localized bugs which have
to be worked around. It's a source distribution world, you can't
say "Fnu compiler is broken, we shall not use it", you have to
work it around if it's not too hard. Seen gnulib?

Yes, I've seen it. It does not seem to mention support for broken
implementations, although it does provide stuff for pre-C89
implementations.

Yes it does support broken C99 implementations.
No, it is supporting *incomplete* C99 implementations. Since they do not
yet *claim* to be conforming to C99 they are not broken.
Now you can say
something about C90, that gnulib example is irrelevant since C90
is the important thing, perhaps because C90 is widely implemented
and so on. And we're back to Win64. Oh, totally forgot, it also
supports some broken C90 implementations.
I doubt it supports Win64 yet, lots of things don't. However, if it is
well written it is unlikely to be bitten by the one area of
non-conformance that has been identified, and including the headers from
a C implementation on Win64 is not likely to break anything.
>>>Provide ONE specific example where a library has a broken header
(give the name and version of the library) which is bad enough to
cause problems with otherwise correct code.

So you can all jump around and yell "those guys are incompetent morons
how cool we are"?

No, to make the point.

Sorry, I misread what you said. What did you ask? What library and what
header? I know an implementation which breaks correct code, and it was
the original thing. I know a library which conforms to C90 and works
on all computers out there (even with C99 since no sane implementation
has small long) but Win64.
It is not inclusion of the standard headers that causes the problem, so
that is not a reason for avoiding including the headers. In fact, if
they used size_t as has been suggested in this thread they should then
it would not cause a problem.

I accept that it is a non-conformance of the 64 bit version of Visual
Studio (A 64 bit implementation of gcc on Win64 could well not be
broken, especially if they ever finish implementing C99).

So that *still* is not a reason to avoid including standard headers and
types, if anything it is an argument *for* using them.
>>>>>>Now, if it's true that one single standard header ever caused
>>problems, then library developers have really good reason to avoid
>>standard headers altogether.
>>
> Balderdash. They should be equally leery of the % operator.
>
I'd think the developers carefully use % operator if it's broken
on some target platform. Is it broken somewhere, did it cause
problems for someone? You seem to imply it.

1+1 is broken on at least one implementation (well, it was something
fundamental like that), should we avoid adding that as a result?

If your code is going to work on that implementation, yes.

Actually, when it was found that the Pentium (I think it was) had a
bug like this there was a major shout about it and MS release a new
version of their compiler (their C implementation was effectively
broken by it) that worked around the processor bug thus leading to a
non-broken implementation. So yes, all the writers of software (or
enough) shouted and screamed about the C implementation now being
broken and waited for it to be fixed instead of working around the
problem themselves.

I'm afraid processor bug is a little different from software bugs.
It was also a bug in the C implementation, one that was fixed under
pressure from everyone else not prepared to work around it.
Broken string functions on some platforms come to mind. Glib has
some stuff to work that around.
I've not seen mention in the documentation of working around broken
string functions, and I've not come across broken string functions. I
have come across ones that don't meet standard they don't claim to meet,
but that is another story.

Can you give a specific example of where it is working around a broken
string library, as opposed to one that does not meet a standard it does
not claim to meet, or one that is correct but does not provide the
functionality they want?
>>>No, you file a bug report on the library (or processor in this case)
and tell your user base not to use it because it is broken.

Totally funny.

I was not one to raise bug reports on the Pentium, but people *did*
and it got fixed but providers of implementations providing
implementations that worked despite the processor bug and Intel fixing
the processor.

What I have done is told customers that given versions of libraries
were broken and that they had to upgrade. I've also told them that
they have to upgrade to newer version of complete OSs. My customers
are orders of magnitude larger than the company I work for.

Good for you, what can I say? Not all people are so lucky, and not all
bugs are processor bugs which are so serious that addition breaks.
No, but a bug making avoidance of including standard headers would be
almost as serious since it would break stupidly large amounts of code.

Telling people they have to upgrade to the new fixed version of some
library is COMMON PRACTICE.
>>>I know, because I work in a commercial organisation and we *do* tell
them that they cannot use certain things with our software because
they are broken.

Well, it's different world. You can't say "don't use glibc" or
"don't use FreeBSD C library" or "don't use operating system
you're using".

I can do it. I know because I HAVE done it. Let's see if I can
remember it...

We told customers they had to upgrade to SCO 5.0.5 because the Java
implementations available for earlier versions were not good enough...

We later told them that they had to upgrade from SCO to Linux because
SCO various libraries we wanted to use were not available on SCO...

We also told another that they would have to upgrade from AIX 4.3 to
either Linux or an up to date version of AIX due to library problems...

We have also told customers when they have reported problems and we
have seen that their systems were out of date to "patch up to the
latest version and test again, if there is still a problem we will
look at it then." So they had to update before we would even look to
see if the problem was in out software or the library!

Again, great for you. Really great and I am glad you can workaround
problems by making them not exist in the first place. If you're saying
it's always possible and easy, you're wrong.
I've yet to come across a situation where it was not possible. Where it
was just awkward but not broken I could not argue it, but where it is
broken it is common practice to tell people they have to upgrade.
>>>>Well, I can't provide any examples of broken standard headers,
I have access only to two systems here, and I am not aware
of some famous example. Does it mean there isn't one? No.
Is there one? I have no idea. Do *I* avoid using standard
headers? *No*. Read the paragraph you replied to?

The contention of everyone else

"everyone else" is three people including you? Perhaps you are right,
I don't know. But I don't know enough to make such a conclusion.

Any such implementation would be basically unusable so it would not
survive.

Such as what exactly? Are you saying implementation with a bug
in a standard header can't survive? I doubt it. Depends on the
bug, doesn't it? Or maybe you're saying there are no implementations
with buggy headers?
I am saying that an implementation with headers that were buggy enough
you could not safely include them would not survive. I have said this
several times. This is also why any such broken implementation would not
be a good reason to avoid using broken headers.
>>>is that there is no implementation worth bothering with that has
headers sufficiently broken to be worth worrying about. There is a
very good reason for this, and such implementation would be well
publicised and boycotted until it was fixed,

You are kidding, right? How about MS?

When building with Visual Studio in include their standard headers
without any problems. So what about MS? They are not an example of
such a broken system.

Um, Win64? Will it be boycotted for making small long type? Or does
it depend on the bug severity?
The standard headers are *not* so broken you cannot safely include them.
The breakage is of a different type. Also, it is not Win64 but the 64
bit version of Visual Studio.
>>Oh, of course, you stopped generalizing and now you are talking about
size_t. Yes, I can't believe there is an implementation which doesn't
have size_t correctly defined in stddef.h. I somehow talked about
the general thing of people not wanting to use standard headers.
You can read it upthread.

I claim that there has been no implementation since 1995 claiming
conformance to any version of the C standard that has been broken for
as long as a month such that including the standard headers in
conforming mode would break correct code. I further claim that even in
non-conforming mode if you avoid anything that clashes with documented
extensions it would still not break.

_GNU_SOURCE thing? No clashes. Or do you mean standard C code? Who
said there are problems with that? See, library (not the C library)
developers may care about non-standard user code.
I mean exactly what I said. It is perfectly safe to include the standard
headers in conforming mode, and if you obey what the documentation tells
you (i.e. use _GNU_SOURCE correctly) it is safe to include them in
non-conforming mode.

I.e. the ONLY time it is NOT safe to include them is when YOU are at
fault. The same applies to authors of libraries. I.e., is is SAFE for
library writers to include standard headers in their headers because
things will only break when YOU do something wrong.

To put it another way, you are WRONG to say that avoiding header bugs
might be a good reason not to include standard headers ANYWHERE.
>>>Again, it is up to *you* to prove your contention that there are
reasons to avoid standard headers due to problems,

I can't prove it, and I am not going to, since I simply don't know
if it's true. But I don't claim it's false just because I don't know
any example.

I do claim it is true because I have some limited understanding of
commercial and open-source realities.

Especially open-source it seems.
I use a lot of open source, so I do know how it works. I have also been
on the wrong end of having the open source community NOT support things.
I just passed the lack of support along the line to customers and told
them we could not support it either and if they wanted to use the new
version of get bug fixes they *needed* they would have to upgrade.
>The reality is that no one can be bothered to deal with severely
broken systems unless they are being paid a lot of money specifically
to do it. So any implementation broken badly enough that including
standard headers is not safe will simply not be used.

Perhaps. Or perhaps not. You seem to be talking about standard
programs which use only standard headers or at least use only
standard features from standard headers.
Read the bits you have quoted earlier where I EXPLICITLY state that the
same rules apply when using the implementation in NON-conforming mode.
You sure every implementation
has its implementation-specific extensions done in good nice
way so you can be sure #includ'ing a standard header behind
user back is safe if user uses those funny extensions?
If you use them you have to read the documentation for them as well, and
then YES, you CAN safely include them. I have been using system
specifics and extensions where appropriate since I started programming
professionally over 20 years ago (not in C back then) and it is safe.
Including on the implementations that people seem to me to complain most
about for providing extensions, gcc and MS Visual Studio.
>>You mean "mian" was relevant to anything?

Yes. If an implementation is so broken that including standard headers
is not safe then it is so broken that anything could be wrong
including the spelling of main.

See? Same thing. From "a header may break user code" you make conclusion
"a standard header may break standard code", though I didn't say that
and my example with _GNU_SOURCE isn't standard.
Last I looked string.h *is* a standard header. However, I EXPLICITLY
stated that it is still safe to include it in non-standard conforming
mode (i.e. using _GNU_SOURCE) as long as YOU read the documentation and
so do it correctly.
>>> But since we're on it, implementation may provide
a separate translation unit which contains definition of main(),
which in turn calls my WinMain.

It can't if it is a hosted implementation.

Yes it can, why can't it? Execution starts in main(), everything
is fine.

If you cannot write your own main function and have that as the entry
point for your program then by *definition* it is not a conforming
hosted implementation.

Who said I can't write my main() function? I can. Or I can ask
implementation to get me builtin translation unit with main()
which would call my FooBarMain().
The STANDARD says that the entry point for YOUR program in a hosted
implementation IS main. If the entry point of YOUR program is NOT main
then either it is NOT a hosted implementation (which is a perfectly
valid thing to be) or it is NOT compliant with the standard.

So if you invoke it so that you do not have to provide main you are NOT
invoking it as a compliant hosted implementation because the STANDARD
says that you have to provide main to a hosted implementation.
>>>It is actually well known that when compiling applications for the
Window GUI using MS VC++ you are using a freestanding implementation.

With MS VC++ maybe. I can use other compilers which *might* use
hidden main(). Can you *prove* (you love proofs don't you) my
favorite compiler doesn't do what I say? (I have no idea what
it does really)

The proof is the definition of a hosted implementation given by the C
standard. It states that the entry point to the program that *you*
write is main, so if the entry point to your code is anything other
than main it does not meet that definition.

And if entry point is indeed main()? Here, let me repeat:
>I can use other compilers which *might* use
>hidden main(). Can you *prove* (you love proofs don't you) my
>favorite compiler doesn't do what I say? (I have no idea what
>it does really)
See everything I said above. The entry point to YOUR program has to be
main, not the entry point to something that calls your program. This is
because that is what the STANDARD says.
>>> I can ask implementation to do it
for me, and it'd be perfectly legal. I have no idea how exactly
it's done in MS implementation, do you? Come on, let's talk about
what's legal and what's not, exactly on point.

WinMain is legal because it is a FREESTANDING implementation, all
appearances to the contrary. When you invoke MS VC++ as a hosted
implementation *you* have to provide main, so it is not a counter
example.

Again, I don't know how to use MS VC++.

That I can believe. A lot of people don't know how to use it properly
as a C compiler. My statement is still true.

I have no idea how to use it properly as a Foo or C++ compiler either.
Nice nit though. Your statement is probably true, I don't really
have doubts about it.
So? You not knowing how to use it does not affect anything I said. MS
having WinMain as the entry point is legal when it is not behaving as a
hosted implementation, so they are fine there. When invoked as a hosted
implementation you have to provide main, so they are still fine.
>>If foo.h includes string.h, then strndup() won't be declared.
Whose problem is this? User's. Why does it happen? Because
user is stupid, he should #define _GNU_SOURCE at the very
beginning. Is the library right? No.

Actually, I believe that if you do:
#define _GNU_SOURCE
#include <foo-thelib.h>
#include <string.h>

void bar (void)
{
strndup ("33", 1);
}

It will all work perfectly unless foo-thelib.h invades the
implementation name space, in which case foo-thelib.h is broken. The
implementation provided headers are perfectly OK.

That's right, that's why I said "user is stupid". So, a third-party
library mandates that stupid things are user's problem. It's quite
sensible, and in fact it's an approach taken by many libraries (glib
too). Now, can you guarantee there are no totally-legitimate non-stupid
things like this _GNU_SOURCE thing which could break?
Yes.
Not necessarily
with standard C headers by the way. sys/stat.h is good too to make
developers wary of standard headers.
sys/stat.h is NOT a reason for developers to be wary of standard headers
and nothing you have said justifies your statement that it is. It would
make just as much sense to say the sinking of the Titanic was a good
reason for developers to be wary of standard headers.
>>>People say the earth is flat, that does not make it true. People
also say the earth is not flat, and them saying that does not make
it true either.

It's not about the truth. It's about you not having right to tell others
people earth is round (it's not, you know).

Freedom of speech. I've got the right to tell you that.

Yes, even though Earth is not round. Maybe "no problems with standard
headers" is just as correct as "Earth is round"? Works fine most of
the time, but not always.
Don't you find it at all strange that you seem to be the only person who
thinks it does not work? Have you not considered that people with vastly
more experience might actually have found that compiler writers take
compliance to C89 seriously and take making their C implementations
usable as intended (i.e. including the standard headers) even more
seriously?
>Equally you have the right to tell me that I am wrong. However, that
is not what is important here. What is important is what is true and
what isn't, if you don't think that then I think a technical group is
the wrong place for you.

I think it's important not to make conclusions from absence of evidence
in technical groups. It's not a court. Exactly.
There is no evidence that you are not a figment of someone's deranged
imagination either.

Generally in both science and technical arenas the person challenging
what is generally believed has to provide some convincing evidence.

<snip>
>It exists to aid porting GNU, part of which *is* an implementation.
There are specific reasons why it still supports pre-C89
implementations (actually, it is only the library they support as
pre-C89). An implementation no having been upgraded to C89 is not
broken as such, just old (or, rather, ancient), but supporting it
requires wrapping various standard library functions and dealing with
not having standard headers, or them not having been upgraded to match
the C89 standard.

So it is *not* an example of working around broken implementations,

It is, if you think of C99 for a minute. stdbool.h and all that. But not
only that of course.
None of the implementations it support claim to be C99 implementations,
therefore working around them not having stdbool.h or not having an
stdbool.h that meets the C99 requirements is NOT working around a broken
implementation, it is working around an implementation being perfectly
correct and not providing what they want.
>only an example of comparability with ancient systems, and they are
slowly moving the goal posts forward.

It also wraps some functions to provide consistent behaviour where the
standard does not require it, for example wrapping malloc so that
their wrapped version when passed a size of 0 will try to allocate a
byte and so return a non-NULL value if possible.

Or fixes some broken string functions for the case when they are
broken in the implementation. You sure it does not work around any
bugs in implementations?
Where? Working around a non-C99 implementation not providing C99
functionality is NOT working around a broken implementation.
>The documentation for gnulib also talks about the fact that it *can*
freely include the standard headers that are available in the oldest
implementation that is supports, so it is definitely *not* an example
of dealing with not being able to include the headers because they are
too broken.

Of course it's not, since gnulib is intended to be a complement to
any-C-library.
So having said it is an example of your point you now accept my
statement that it is not an example of my point.

Oh, just so you know I've decided that since you seem unable to >
understand the points others and I have made (several times above you
say you don't understand, or close enough) there is no point arguing
further with you. Believe what you will and the rest of us will be happy
knowing that we can always safely include standard headers and use
size_t, even with the small break that MS Visual Studio for Win64, since
that does not break well written code.
--
Flash Gordon
Mar 17 '07 #61
On Mar 17, 3:29 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
Yevgen Muntyan wrote, On 17/03/07 01:20:
Flash Gordon wrote:
....
Oh, and one comment I found particularly amusing. 'These are useful
because a "gint8" can be adjusted to be 1 byte (8 bits) on all
platforms.' Ignoring the terminology problem, if char is not 8 bits
you are stuffed in terms of finding an 8 bit type!
You surely know that char is not signed char,

Yes, I know that. However, no typedef will allow you to provide an 8 bit
type is one does not exist and if char is not 8 bits one does not exist.
If, as you suggest, there reason is due to variability in the signedness
of plain char then one would expect them to state this and possibly
actually use signed char, since otherwise using a common option on gcc
on linux platforms will stop the typedef doing what they want.
Care to show that typedef? I have here

typedef signed char gint8;
typedef unsigned char guint8;

Documentation:

gint8

typedef signed char gint8;

A signed integer guaranteed to be 8 bits on all platforms. Values of
this type can range from -128 to 127.

guint8

typedef unsigned char guint8;

An unsigned integer guaranteed to be 8 bits on all platforms. Values
of this type can range from 0 to 255.
I.e. that comment is still highly amusing to me for the lack of
knowledge it shows.
Sure, totally incompetent people.

Yevgen

Mar 18 '07 #62
On Mar 17, 3:29 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
Yevgen Muntyan wrote, On 17/03/07 01:20:
Flash Gordon wrote:
Yevgen Muntyan wrote, On 16/03/07 22:46:
....
>I did *not* say glib avoids using standard headers. It does not, in
fact. It does avoid string.h,
It does not. At least, not in the version installed on this machine.
markg@brenda:/usr/include/glib-2.0/gobject$ grep string.h *
gobjectnotifyqueue.c:#include <string.h/* memset */
Um, so you did not understand I was talking about standard headers
in *headers*?

It's not my fault if they put a .c file in the includes directory which
is specifically for include files hence the name include. Since they
include header guards (again in a way that invades the implementation
name space) there is a strong suggestion that they expect people to
include it. As does the fact that it is only providing static functions,
typedefs, and struct definitions. Therefore I believe it *is* a header
file, it just does not have the conventional name.
I admit, I had no idea about this file. Indeed, looks like some
special-purpose private header. There are few others like that, it
doesn't change a thing.
#include <glib.hwhich pulls everything from the glib library won't
get string.h for you. Moreover, even if you use <glib-object.h>, which
is the GObject main header (it's not part of the glib proper), you
won't get gobjectnotifyqueue.c nor
will you get string.h. Moreover, the documented and the legal way to
use libgobject is <glib-gobject.h>, you may not use individual headers
(the .h files you can see in gobject/ folder) with one documented
exception (not this file).
If you really thought I was talking about library
sources, I apologize, and I must admit all I said seemed like
hundred times more stupid than I thought it did. Of course I meant
headers. Why do you think I was talking about that _GNU_SOURCE thing?
Because some glib source file is using it? Just to be clear,
#include <glib.h>
won't make declaration of strlen() visible. But size_t will be
defined.

No, but #include <gobjectnotifyqueue.cwill, and if you actually loot
at it you will see that is its intended use.
No, you will get a compilation error. But it's details of course.
Indeed, a header. Undocumented, private header. Not even part of
libglib (the <glib.hthing).

....
Some of the things in glib suggest trying to deal with pre-ANSI C, for
example defining NULL if it is not defined. Either that or it shows a
stupid (in my opinion) lack of trust in the standard libraries. The
same applies to the provision of an equivalent of the standard
offsetof macro.
There is also invasion of the implementations name space with struct
_GSource etc.
So yes, there is certainly some grounds to say that the author(s) do
not know C properly.
Yeah, sure. Especially the last thing, about underscore-prefixed
identifiers. "Some grounds", huh? Indeed, some grounds. Now can
you say it in plain text, "glib developers are incompetent"?
Mumbling "some ground" surely helps not to lose face and still
make yourself right. Please make the claim you seem to be defending.

I require a lot more investigation or discussion with the developers to
state categorically that they are incompetent, but as I say the evidence
points to significant holes in their knowledge.
Well, let me make a conclusion. Bugs in your software present evidence
of your incompetence. I could even say that you are incompetent or
hostile, since you are producing software with bugs. Or not?

[snip]

Yevgen

Mar 18 '07 #63
On Mar 17, 4:50 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
Yevgen Muntyan wrote, On 17/03/07 00:04:
Flash Gordon wrote:
[snip]
The documentation for gnulib also talks about the fact that it *can*
freely include the standard headers that are available in the oldest
implementation that is supports, so it is definitely *not* an example
of dealing with not being able to include the headers because they are
too broken.
Of course it's not, since gnulib is intended to be a complement to
any-C-library.

So having said it is an example of your point you now accept my
statement that it is not an example of my point.
Same thing again. I said gnulib is an example of how people work
around bugs in implementation. I did *not* say it's an example of how
people avoid using standard headers. Whatever.
I brought gnulib in here because you said implementations are never
broken enough to have to workaround bugs in them. Sorry if it wasn't
clear. I believe I did say explicitly (not once) example of what
gnulib is.
Oh, just so you know I've decided that since you seem unable to >
understand the points others and I have made (several times above you
say you don't understand, or close enough) there is no point arguing
further with you.
Absolutely. There is no point in talking to you if you are unwilling
not to hear what I didn't say.
Believe what you will and the rest of us will be happy
knowing that we can always safely include standard headers and use
size_t, even with the small break that MS Visual Studio for Win64, since
that does not break well written code.
Did I say one single time that (not) #includ'ing standard headers may
be a problem with Win64? You're playing word games here, you are
composing different things I said into one as you desire, and make me
say whatever nonsense you want me to say.

So you be happy including standard headers. I am happy including
standard headers too, you know. And?

Yevgen

Mar 18 '07 #64
mu*****@gmail.com wrote, On 18/03/07 00:41:
On Mar 17, 3:29 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
>Yevgen Muntyan wrote, On 17/03/07 01:20:
>>Flash Gordon wrote:
...
>>>Oh, and one comment I found particularly amusing. 'These are useful
because a "gint8" can be adjusted to be 1 byte (8 bits) on all
platforms.' Ignoring the terminology problem, if char is not 8 bits
you are stuffed in terms of finding an 8 bit type!
You surely know that char is not signed char,
Yes, I know that. However, no typedef will allow you to provide an 8 bit
type is one does not exist and if char is not 8 bits one does not exist.
If, as you suggest, there reason is due to variability in the signedness
of plain char then one would expect them to state this and possibly
actually use signed char, since otherwise using a common option on gcc
on linux platforms will stop the typedef doing what they want.

Care to show that typedef? I have here
OK. http://developer.gnome.org/doc/API/g...pes.html#GCHAR
Straight on THEIR web site. It is entirely possible that their
documentation does not reflect their code, but that would not be a good
sign either.

I've uninstalled the development package since I don't need it, so I
won't be checking the actual code.
typedef signed char gint8;
typedef unsigned char guint8;

Documentation:

gint8

typedef signed char gint8;

A signed integer guaranteed to be 8 bits on all platforms. Values of
this type can range from -128 to 127.
As stated, there is no guarantee in C that there is ANY such type.
Providing the typedef solves exactly NO problems.

<snip>
>I.e. that comment is still highly amusing to me for the lack of
knowledge it shows.

Sure, totally incompetent people.
No one has said totally incompetent, I certainly have not. You do keep
pointing at evidence suggesting it though.
--
Flash Gordon
Mar 18 '07 #65
mu*****@gmail.com wrote, On 18/03/07 00:51:
On Mar 17, 3:29 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
>Yevgen Muntyan wrote, On 17/03/07 01:20:
>>Flash Gordon wrote:
Yevgen Muntyan wrote, On 16/03/07 22:46:
...
>>>>I did *not* say glib avoids using standard headers. It does not, in
^^^^
>>>>fact. It does avoid string.h,
^^^^^^^^^^^^^^^^^^^^^^^
>>>It does not. At least, not in the version installed on this machine.
markg@brenda:/usr/include/glib-2.0/gobject$ grep string.h *
gobjectnotifyqueue.c:#include <string.h/* memset */
Um, so you did not understand I was talking about standard headers
in *headers*?
It's not my fault if they put a .c file in the includes directory which
is specifically for include files hence the name include. Since they
include header guards (again in a way that invades the implementation
name space) there is a strong suggestion that they expect people to
include it. As does the fact that it is only providing static functions,
typedefs, and struct definitions. Therefore I believe it *is* a header
file, it just does not have the conventional name.

I admit, I had no idea about this file. Indeed, looks like some
special-purpose private header. There are few others like that, it
doesn't change a thing.
It does. You said glib avoids it and yet there it is using it in a file
provided WHITHOUT installing the sources.
#include <glib.hwhich pulls everything from the glib library won't
get string.h for you. Moreover, even if you use <glib-object.h>, which
is the GObject main header (it's not part of the glib proper), you
won't get gobjectnotifyqueue.c nor
will you get string.h. Moreover, the documented and the legal way to
use libgobject is <glib-gobject.h>, you may not use individual headers
(the .h files you can see in gobject/ folder) with one documented
exception (not this file).
Either they are showing lack of competence by including it in that
directory (I did NOT install the sources, only the packages to develop
using it) or they include string.h in a file users of the library are
intended to use. Take your choice, I don't care which it is since I
don't develop with it.
> If you really thought I was talking about library
>>sources, I apologize, and I must admit all I said seemed like
hundred times more stupid than I thought it did. Of course I meant
headers. Why do you think I was talking about that _GNU_SOURCE thing?
Because some glib source file is using it? Just to be clear,
#include <glib.h>
won't make declaration of strlen() visible. But size_t will be
defined.
No, but #include <gobjectnotifyqueue.cwill, and if you actually loot
at it you will see that is its intended use.

No, you will get a compilation error. But it's details of course.
Including a .c file does NOT cause a compilation error.
Indeed, a header. Undocumented, private header. Not even part of
libglib (the <glib.hthing).
If it is private it should not be placed in the directory for public
headers. In fact, as I did not install the sources it should not be
installed at all. So either you are wrong and it is intended to be used
or they are wrong for putting it their. Take your pick.
>>>Some of the things in glib suggest trying to deal with pre-ANSI C, for
example defining NULL if it is not defined. Either that or it shows a
stupid (in my opinion) lack of trust in the standard libraries. The
same applies to the provision of an equivalent of the standard
offsetof macro.
There is also invasion of the implementations name space with struct
_GSource etc.
So yes, there is certainly some grounds to say that the author(s) do
not know C properly.
Yeah, sure. Especially the last thing, about underscore-prefixed
identifiers. "Some grounds", huh? Indeed, some grounds. Now can
you say it in plain text, "glib developers are incompetent"?
Mumbling "some ground" surely helps not to lose face and still
make yourself right. Please make the claim you seem to be defending.
I require a lot more investigation or discussion with the developers to
state categorically that they are incompetent, but as I say the evidence
points to significant holes in their knowledge.

Well, let me make a conclusion. Bugs in your software present evidence
of your incompetence. I could even say that you are incompetent or
hostile, since you are producing software with bugs. Or not?
Bugs in my software are pointers towards where either my knowledge or
skill are lacking, if there are enough then it indicates I am
incompetent. The same applies to everyone else. You can decide you thing
me incompetent or hostile if you like, I really don't care.

Anyway, I said it was not worth arguing with you, and now I'll act on
it. Have the last word if you want since I won't read it.
--
Flash Gordon
Mar 18 '07 #66
On Mar 18, 4:32 am, Flash Gordon <s...@flash-gordon.me.ukwrote:
munt...@gmail.com wrote, On 18/03/07 00:41:
On Mar 17, 3:29 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
Yevgen Muntyan wrote, On 17/03/07 01:20:
>Flash Gordon wrote:
...
>>Oh, and one comment I found particularly amusing. 'These are useful
because a "gint8" can be adjusted to be 1 byte (8 bits) on all
platforms.' Ignoring the terminology problem, if char is not 8 bits
you are stuffed in terms of finding an 8 bit type!
You surely know that char is not signed char,
Yes, I know that. However, no typedef will allow you to provide an 8 bit
type is one does not exist and if char is not 8 bits one does not exist.
If, as you suggest, there reason is due to variability in the signedness
of plain char then one would expect them to state this and possibly
actually use signed char, since otherwise using a common option on gcc
on linux platforms will stop the typedef doing what they want.
Care to show that typedef? I have here

OK.http://developer.gnome.org/doc/API/g...pes.html#GCHAR
Straight on THEIR web site.
The documentation you cited is from 5 years old package, not from
headers you looked at. It doesn't change the fact that the actual
typedefs in actual code of that ancient package are

typedef signed char gint8;
typedef unsigned char guint8;
It is entirely possible that their
documentation does not reflect their code, but that would not be a good
sign either.
Of course, it would be a sign of usual problem with documentation.
Docs suck, way too often. They improve with time though.
I've uninstalled the development package since I don't need it, so I
won't be checking the actual code.
Of course, it's easier to get irrelevant docs and claim given software
package is written by incompetent people.
typedef signed char gint8;
typedef unsigned char guint8;
Documentation:
gint8
typedef signed char gint8;
A signed integer guaranteed to be 8 bits on all platforms. Values of
this type can range from -128 to 127.

As stated, there is no guarantee in C that there is ANY such type.
Providing the typedef solves exactly NO problems.
"There is no guarantee in C". So?
gint8 *is* a signed integer guaranteed to be 8 bits on all platforms
where glib works. Values of this type can range from -128 to 127. Try
to disprove it. Provide an example of implementation where gint8 won't
be 8 bits and its range won't be -128..127. Oops, you can't, right?
Since glib isn't going to work on that platform even if you find it in
some computing museum.
<snip>
I.e. that comment is still highly amusing to me for the lack of
knowledge it shows.
Sure, totally incompetent people.

No one has said totally incompetent, I certainly have not. You do keep
pointing at evidence suggesting it though.
Yeah. Sure.

Mar 18 '07 #67
On Mar 18, 4:43 am, Flash Gordon <s...@flash-gordon.me.ukwrote:
munt...@gmail.com wrote, On 18/03/07 00:51:On Mar 17, 3:29 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
Yevgen Muntyan wrote, On 17/03/07 01:20:
>Flash Gordon wrote:
Yevgen Muntyan wrote, On 16/03/07 22:46:
...
>>>I did *not* say glib avoids using standard headers. It does not, in

^^^^>>>>fact. It does avoid string.h,

^^^^^^^^^^^^^^^^^^^^^^^
>>It does not. At least, not in the version installed on this machine.
markg@brenda:/usr/include/glib-2.0/gobject$ grep string.h *
gobjectnotifyqueue.c:#include <string.h/* memset */
Um, so you did not understand I was talking about standard headers
in *headers*?
It's not my fault if they put a .c file in the includes directory which
is specifically for include files hence the name include. Since they
include header guards (again in a way that invades the implementation
name space) there is a strong suggestion that they expect people to
include it. As does the fact that it is only providing static functions,
typedefs, and struct definitions. Therefore I believe it *is* a header
file, it just does not have the conventional name.
I admit, I had no idea about this file. Indeed, looks like some
special-purpose private header. There are few others like that, it
doesn't change a thing.

It does. You said glib avoids it and yet there it is using it in a file
provided WHITHOUT installing the sources.
What it provides in some file doesn't mean anything. It may install
anything. What's important is what it has in documented public
headers. Go find some fun code in /usr/include/sys/bits/ and then try
to make some conclusions like "it's there, installed, I can use it".
>
#include <glib.hwhich pulls everything from the glib library won't
get string.h for you. Moreover, even if you use <glib-object.h>, which
is the GObject main header (it's not part of the glib proper), you
won't get gobjectnotifyqueue.c nor
will you get string.h. Moreover, the documented and the legal way to
use libgobject is <glib-gobject.h>, you may not use individual headers
(the .h files you can see in gobject/ folder) with one documented
exception (not this file).

Either they are showing lack of competence by including it in that
directory (I did NOT install the sources, only the packages to develop
using it) or they include string.h in a file users of the library are
intended to use. Take your choice, I don't care which it is since I
don't develop with it.
If you really thought I was talking about library
>sources, I apologize, and I must admit all I said seemed like
hundred times more stupid than I thought it did. Of course I meant
headers. Why do you think I was talking about that _GNU_SOURCE thing?
Because some glib source file is using it? Just to be clear,
#include <glib.h>
won't make declaration of strlen() visible. But size_t will be
defined.
No, but #include <gobjectnotifyqueue.cwill, and if you actually loot
at it you will see that is its intended use.
No, you will get a compilation error. But it's details of course.

Including a .c file does NOT cause a compilation error.
Your #include directive does, unless you are using undocumented
include paths. Try compiling programs installed on your computer with -
I/usr/include/bits/ and you'll see what happens. Of course you can
include any file, I didn't say you can't. Question is what it means,
when you include random file to prove some points (just like some
other guy, huh? correct to the end)
>
Indeed, a header. Undocumented, private header. Not even part of
libglib (the <glib.hthing).

If it is private it should not be placed in the directory for public
headers.
Of course, Flash Gordon said.
In fact, as I did not install the sources it should not be
installed at all. So either you are wrong and it is intended to be used
I bet it is intended to be used if it's there. Question is how and
what for and by whom.
or they are wrong for putting it their. Take your pick.
>>Some of the things in glib suggest trying to deal with pre-ANSI C, for
example defining NULL if it is not defined. Either that or it shows a
stupid (in my opinion) lack of trust in the standard libraries. The
same applies to the provision of an equivalent of the standard
offsetof macro.
There is also invasion of the implementations name space with struct
_GSource etc.
So yes, there is certainly some grounds to say that the author(s) do
not know C properly.
Yeah, sure. Especially the last thing, about underscore-prefixed
identifiers. "Some grounds", huh? Indeed, some grounds. Now can
you say it in plain text, "glib developers are incompetent"?
Mumbling "some ground" surely helps not to lose face and still
make yourself right. Please make the claim you seem to be defending.
I require a lot more investigation or discussion with the developers to
state categorically that they are incompetent, but as I say the evidence
points to significant holes in their knowledge.
Well, let me make a conclusion. Bugs in your software present evidence
of your incompetence. I could even say that you are incompetent or
hostile, since you are producing software with bugs. Or not?

Bugs in my software are pointers towards where either my knowledge or
skill are lacking, if there are enough then it indicates I am
incompetent. The same applies to everyone else. You can decide you thing
me incompetent or hostile if you like, I really don't care.
I decide you are hostile, I don't think you are incompetent. Your
hostility is caused by me not taking your "we think so" as a 100%
proof of anything.
Anyway, I said it was not worth arguing with you,
And still arguing, huh?
and now I'll act on
it. Have the last word if you want since I won't read it.
Well, whatever. You are the man who supports insulting people without
having enough information to judge about their competence. Insulting
them just to stay right in the argument; insulting because you can't
admit they might be not bad because it would mean *I* am right in
something here.

See, your problem, and problem of some other peple here is you make
conclusions too fast and too often those conclusions are rather
baseless. Or based solely on your experience. While your experience
may be huge, it's still surely very narrow. And experience of five
people is still way too narrow to judge about *everything*. Or perhaps
I am wrong and collective experience and knowledge of these five
people is indeed big enough, and together you know everything and you
may judge everything. Or am I?

Mar 18 '07 #68
On Mar 18, 4:32 am, Flash Gordon <s...@flash-gordon.me.ukwrote:
munt...@gmail.com wrote, On 18/03/07 00:41:
On Mar 17, 3:29 pm, Flash Gordon <s...@flash-gordon.me.ukwrote:
Yevgen Muntyan wrote, On 17/03/07 01:20:
>Flash Gordon wrote:
...
>>Oh, and one comment I found particularly amusing. 'These are useful
because a "gint8" can be adjusted to be 1 byte (8 bits) on all
platforms.' Ignoring the terminology problem, if char is not 8 bits
you are stuffed in terms of finding an 8 bit type!
You surely know that char is not signed char,
Yes, I know that. However, no typedef will allow you to provide an 8 bit
type is one does not exist and if char is not 8 bits one does not exist.
If, as you suggest, there reason is due to variability in the signedness
of plain char then one would expect them to state this and possibly
actually use signed char, since otherwise using a common option on gcc
on linux platforms will stop the typedef doing what they want.
Care to show that typedef? I have here

OK.http://developer.gnome.org/doc/API/g...pes.html#GCHAR
Straight on THEIR web site. It is entirely possible that their
documentation does not reflect their code, but that would not be a good
sign either.
Sorry, can't resist. It's not just some outdated docs, the link points
to this:

gchar
typedef char gchar;
Corresponds to the standard C char type.

You are not going to read it, too bad, maybe you indeed could provide
the *typedef* I asked you for, or provide a link to the docs you
didn't like so much.
See, I trusted you, and I supposed you knew what you were talking
about, and I assumed it was docs bug. Whatever. It's so much better to
whine a little "oh they are incompetent morons their docs are so
amusing".

Mar 18 '07 #69
On Fri, Mar 16, 2007 at 02:08:15PM +0000, Flash Gordon set bits thusly:
Newsgroups: comp.lang.c
Date: Fri, 16 Mar 2007 14:08:15 +0000
From: Flash Gordon <sp**@flash-gordon.me.uk>
Subject: Re: C89, size_t, and long

Yevgen Muntyan wrote, On 16/03/07 03:57:
Eric Sosman wrote:
>Yevgen Muntyan wrote:
Eric Sosman wrote:
Yevgen Muntyan wrote:
This Win64 thing is funny, because no other 'popular' system
has small long type. Good or bad, but lot of useful software is
written
under many assumptions like 8-bit bytes, ASCII, long >= size_t. Simply
ignoring it won't always work since you might actually need that
software (you know, libraries which have useful stuff).

Do you have a specific library in mind, or are you "just
supposing?" If the latter, drop it until the situation actually
arises. If the former, please tell us about it so we'll be warned
not to use that organization's products.

I do have a specific library in mind, indeed. It's not written by me
or my friends or relatives. It's a widely used and indeed useful
library.

... which you have not named, to warn us away from it.
That's right. Somehow I don't believe you. And somehow I don't want
bring names in this context. Those guys are not hostile, unlike you.

If you are not prepared to provide evidence for you claims then do not
expect people to take them seriously.
<delurk>

Reading this thread has made me curious about the library under discussion.
If the OP refuses to name the library, perhaps there is a good reason for
it. Perhaps the licensing terms forbid it? Whatever the case it would
seem that the argument is indeed progressing without a concrete subject,
that is an example, and as such is ultimately futile.

Maybe the OP should do whatever it is he has to do in order to provide the
specific example in this instance so he may then be taken seriously.
Otheriwse, I would say he has no basis whatsoever for argument or discussion.
Regards,

Steve

Mar 18 '07 #70
On Mar 18, 3:40 pm, "Steve Thompson" <steve49...@yahoo.ca.cawrote:
On Fri, Mar 16, 2007 at 02:08:15PM +0000, Flash Gordon set bits thusly:
[snip]
>
<delurk>

Reading this thread has made me curious about the library under discussion.
If the OP refuses to name the library, perhaps there is a good reason for
it.
Yes, the reason was that the library developers were called
incompetent by a man who had no idea who he was talking about, or what
code he was talking about. I even suspect that the library developers
are much more competent than that man.
Yes, I didn't want to bring the names in here, naturally.

In any case I did name it (not even today or yesterday), it's glib.
Maybe the OP should do whatever it is he has to do in order to provide the
specific example in this instance so he may then be taken seriously.
Maybe you should read the thread if you really care? I understand you
don't care, and I understand you have no desire to read this stupid
thread. But perhaps avoid comments on it in this case?
Otheriwse, I would say he has no basis whatsoever for argument or discussion.
But opponents surely do have basis for reading what I didn't write and
for calling others incompetent in conclusion from whatever they made
up in their mind. So, one says "those guys are incompetent, who are
those guys?", and it's fine. Me not saying who those guys are means I
have no basis for argument or discussion. Yeah.

Mar 18 '07 #71
On Sun, Mar 18, 2007 at 04:04:48PM -0700, mu*****@gmail.com set bits thusly:
Newsgroups: comp.lang.c
Date: 18 Mar 2007 16:04:48 -0700
From: mu*****@gmail.com
Subject: Re: C89, size_t, and long

On Mar 18, 3:40 pm, "Steve Thompson" <steve49...@yahoo.ca.cawrote:
On Fri, Mar 16, 2007 at 02:08:15PM +0000, Flash Gordon set bits thusly:
[snip]

<delurk>

Reading this thread has made me curious about the library under discussion.
If the OP refuses to name the library, perhaps there is a good reason for
it.

Yes, the reason was that the library developers were called
incompetent by a man who had no idea who he was talking about, or what
code he was talking about. I even suspect that the library developers
are much more competent than that man.
Yes, I didn't want to bring the names in here, naturally.
Naturally? It's not like the authors of glib are working in secret,
distributing their code under an NDA to a select group of clients. (And
even so, discussing it in roundabout terms would still likely constitute a
violation of the NDA.) In any case, your refusal to name names until
called on it is ... specious.
In any case I did name it (not even today or yesterday), it's glib.
Maybe the OP should do whatever it is he has to do in order to provide the
specific example in this instance so he may then be taken seriously.

Maybe you should read the thread if you really care? I understand you
don't care, and I understand you have no desire to read this stupid
thread. But perhaps avoid comments on it in this case?
News propogation is not necessarily ideal. My ISP believes that Usenet is
a non-essential service and therefore fails to maintain a decent spool. In
order to get the remaining posts and read your reply in a timely fashion, I
had to specifically use another source. Don't piss on my head about
'reading the thread', dickwad, I had no idea my view of the thread was out
of date.
Otheriwse, I would say he has no basis whatsoever for argument or discussion.

But opponents surely do have basis for reading what I didn't write and
for calling others incompetent in conclusion from whatever they made
up in their mind. So, one says "those guys are incompetent, who are
those guys?", and it's fine. Me not saying who those guys are means I
have no basis for argument or discussion. Yeah.
There are assholes all over Usenet who will make up their opinions _a
priori_ based on their prejudices or corporate affilliation. When they
apply said prejudices to discussions in complete opposition to the text, it
is usually rather obvious. If you wish to argue with them, and on their
level, feel free to do so. But don't become all bitchy when it is noted
that you lose the battle right at the outset when you engage them on their
terms.

Personally, after finally reading all the messages in the thread, I think
you're full of shit. If pushed, I would venture to say that you write in
order to hear yourself speak, and for the attention (good or bad) that your
misguided arguments draw. As for the intellectual or ethical value of your
position and posture: trivial.
Regards,

Steve

Mar 19 '07 #72
On Mar 18, 8:20 pm, "Steve Thompson" <steve49...@yahoo.ca.cawrote:
On Sun, Mar 18, 2007 at 04:04:48PM -0700, munt...@gmail.com set bits thusly:
Newsgroups: comp.lang.c
Date: 18 Mar 2007 16:04:48 -0700
From: munt...@gmail.com
Subject: Re: C89, size_t, and long
On Mar 18, 3:40 pm, "Steve Thompson" <steve49...@yahoo.ca.cawrote:
On Fri, Mar 16, 2007 at 02:08:15PM +0000, Flash Gordon set bits thusly:
[snip]
<delurk>
Reading this thread has made me curious about the library under discussion.
If the OP refuses to name the library, perhaps there is a good reason for
it.
Yes, the reason was that the library developers were called
incompetent by a man who had no idea who he was talking about, or what
code he was talking about. I even suspect that the library developers
are much more competent than that man.
Yes, I didn't want to bring the names in here, naturally.

Naturally? It's not like the authors of glib are working in secret,
distributing their code under an NDA to a select group of clients. (And
even so, discussing it in roundabout terms would still likely constitute a
violation of the NDA.) In any case, your refusal to name names until
called on it is ... specious.
I didn't want to name it because if one of glib developers reads this
stuff occasionally, I would be ashamed. Because I bring their code as
an example of wrong bad code which violates all the holy principles. I
didn't mean it, I didn't say it, others did, but it doesn't change a
thing.

Now, leaving aside my irrelevant psychological reasons not to name it,
this thing:
>>Maybe the OP should do whatever it is he has to do in order to provide the
specific example in this instance so he may then be taken seriously.
Specific example of freaking what? Of a library which uses long
instead of size_t? Man, turn on your brain and use grep, try grepping
for "alloc", you'll find some examples of such things on your unixish
system. If you're on windows, it sucks, you have to use koders.com.
Now, if you don't want to that, it means you don't care. If you don't
believe there are libraries which do things like that then you either
believe in bugless software, or you believe in UFO, or <insert
whatever you like>
In any case I did name it (not even today or yesterday), it's glib.
Maybe the OP should do whatever it is he has to do in order to provide the
specific example in this instance so he may then be taken seriously.
Maybe you should read the thread if you really care? I understand you
don't care, and I understand you have no desire to read this stupid
thread. But perhaps avoid comments on it in this case?

News propogation is not necessarily ideal. My ISP believes that Usenet is
a non-essential service and therefore fails to maintain a decent spool. In
order to get the remaining posts and read your reply in a timely fashion, I
had to specifically use another source. Don't piss on my head about
'reading the thread', dickwad, I had no idea my view of the thread was out
of date.
It was my mistake, and I am sorry for it, but your view of the thread
was up-to-date enough for not pissing on my head about your view of
presented evidence and other shit.

Mar 19 '07 #73
On Sun, Mar 18, 2007 at 07:08:57PM -0700, mu*****@gmail.com set bits thusly:
>
It was my mistake, and I am sorry for it, but your view of the thread
was up-to-date enough for not pissing on my head about your view of
presented evidence and other shit.
Sorry and $1.75 CAD will get you a fuckin' coffee at Starbucks. HTH.
Regards,

Steve

Mar 19 '07 #74

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

18
by: rayw | last post by:
I used to believe that size_t was something to do with integral types, and the std. Something along the lines of .. a char is 8 bits, a int >= a char a long >= int
23
by: bwaichu | last post by:
To avoid padding in structures, where is the best place to put size_t variables? According the faq question 2.12 (http://c-faq.com/struct/padding.html), it says: "If you're worried about...
318
by: jacob navia | last post by:
Rcently I posted code in this group, to help a user that asked to know how he could find out the size of a block allocated with malloc. As always when I post something, the same group of people...
22
by: subramanian100in | last post by:
Consider the following program #include <limits.h> #include <stddef.h> int main(void) { size_t size; size_t bytes = sizeof(size_t);
24
by: Paulo Matos | last post by:
Hello, Is it safe to assume a size_t is an unsigned long? (is it forced by the standard?) Thank you, Paulo Matos
9
by: Bob Cassel | last post by:
I have the idea that ptr_diff_t had to be the same size as size_t from Plauger's "The Standard C Library," where he states "... It is always the signed type that has the same number of bits as the4...
8
by: lubomir dobsik | last post by:
hi, i have seen an interesting thing: #if sizeof((char*)0 - (char*)0) == sizeof(unsigned int) typedef unsigned int size_t; #elif sizeof((char*)0 - (char*)0) == sizeof(unsigned long) typedef...
89
by: Tubular Technician | last post by:
Hello, World! Reading this group for some time I came to the conclusion that people here are split into several fractions regarding size_t, including, but not limited to, * size_t is the...
50
by: jacek.dziedzic | last post by:
Hi! On a machine where size_t is 64-bit, unsigned long is 32-bit, how does one construct a size_t literal that says 2^32? Typing in size_t x = 4294967296UL; complains about the value being...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.