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
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"
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.
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
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
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.
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.
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.
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.
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
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
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
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
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 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 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
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.
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?
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".
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
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.
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
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.
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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
|
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...
|
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...
|
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);
|
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
|
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...
|
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...
|
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...
|
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...
|
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...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
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...
|
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...
|
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...
|
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)...
|
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...
|
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....
|
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...
| | |