J
John Kelly
Or trim_(). Another level would be trim__(), etc.
If you want to pursue that idea, the code is available to you.
Or trim_(). Another level would be trim__(), etc.
If you want to pursue that idea, the code is available to you.
J
John Kelly
Who says it's non standard? You?
Do you want to help, or waste my time?
K
Keith Thompson
John Kelly said:
The ISO C Standard, specifically section 7.5.
The fact that a reasonably popular implementation doesn't support it
should also be a clue that it's non-standard.
Do dispute the statement that it's non-standard?
He's trying to help, but he appears to be wasting his time (though
someone else might benefit from the discussion).
F
Francesco S. Carta
As I have repeatedly stated, there is no physical evidence about the
existence of such a define in the whole MinGW packages I downloaded, and
once more, the problem about EOVERFLOW is completely up to you to solve,
assuming you consider it a problem.
I'm not accustomed to impose my contribution where it is not welcome,
custom which lead to one and only logical conclusion.
S
Seebs
Well, the language spec.
If you could perceive anything as help which did not consist entirely of
supporting you in whatever idiocy you've undertaken, whether or not it
makes any sense, I think a lot of people would be glad to help you.
Instead, you're sitting here demanding that skilled marksmen and gunsmiths
help you smooth out the inside of the barrel of a gun because the reason
it doesn't shoot straight is that there's some kind of grooves on the inside
of the barrel that make the bullet spin, and that makes it shoot wrong.
-s
I
Ian Collins
I bow to a higher authority.
Do you want to learn, or do you know all you need to know?
J
John Kelly
If many platforms have it, that's a practical standard more important to
me.
I don't dispute that you and your tag team partners are wasting my time.
S
Seebs
That's not a standard, that's a common occurrence.
And the thing is...
This actually IS an interesting and topical discussion. How do you decide
what's "standard enough"? As a general rule, I advocate the following
policy:
When considering the use of a feature, weigh its portability against its
value to you.
As an example: I believe that snprintf() is close enough to universally
accessible that I don't even consider not-using-snprintf. I use it, I use
it consistently, and if some day I encounter a system which lacks it, I
figure I'll grab the source from one of the BSDs. (Since I work on embedded
Linux mostly these days, I'm not worried about people being afraid of
open source.)
But I do that because I've found that snprintf() is extremely useful to me
in clearly, idiomatically, and safely implementing a common requirement.
I would never use EOVERFLOW unless it were mandated by a specification, and
I would object to any specification which mandated it. That's because I
consider it an unnecessary extension that doesn't give much specific
information. (I'm not even sure it's sensical in the context of a trim
function, for that matter.) It's not that it's all that unportable; it's
just that there's no marginal benefit.
I'll put up with a great deal of non-portability if necessary; I use
the RTLD_NEXT feature of a dynamic linker, even though it's a local
extension that isn't particularly portable, because there is NO other
way to accomplish the thing I want to do, so far as I can tell. Certainly
no practical one.
I think the issue here is not just how portable or non-portable EOVERFLOW
is, but that it's not particularly improving the utility of the code to
rely on it. That, and more generally, your complete lack of interest in
anyone's needs but your own is pretty much pathological. That is not a sane
way for a human to live.
-s
J
James
John Kelly said:
Sounds okay to me.
I already did the low level trim_ex() here:
http://groups.google.com/group/comp.lang.c/msg/297f4cd484882b20
Coding the trim() would be trivial due to the "detailed" information
provided by trim_ex().
BTW, the trim_ex() function returns failure (e.g., returns zero), if you
pass it a string that happens to have a size grater than SIZE_MAX. Not sure
how practical that safe guard is, but its there anyway.
G
Geoff
I must agree with Keith, check the documentation for your implementation.
Grepping might find it but it won't tell you the proper way to include it for
your implementation. For example, in VS 2010 it's defined in <errno.h>, has the
value 132 and is documented as being a POSIX supplement. John is using it
because it fits his environment because Interix is a POSIX based implementation
of UNIX services for Windows. The values in his environment for EINVAL and
EOVERFLOW are different from mine.
U
Uno
Seebs said:
The more-troubling scenario is when we who are looking to improve our
game with C run onto a question that isn't pure enough to be discussed
around you and your pushy, ideological friends.
.... or ... you can just not post the "go somewhere else to find an
answer," and of course leave that place unnamed. In the Southwest, we
just usually say "**** off."
You know, Peter, I'm a practicing lousy Christian, and I thought I'd try
to figure out what you're damage is, so I googled you:
http://i34.tinypic.com/35hkdwg.jpg
One thing I learned in so doing is that you are an englishman. I didn't
know that, but that is the nationality of the majority of Topic Fundies
in c.l.c., so that would make sense.
However, you looked like a guy I would be friends with in real life. I
was honestly expecting you to be twenty years older and freakishly
scarred or malformed. Why is that?
Peter, a person's C source is more personal than poetry. It's hard
enough to not take criticism emotionally, and the vicissitudes of usenet
don't make that easier. Many times, others can't read all the posts. I
notice this very frequently, as I have several newsreaders on different
platforms.
C.l.c. has come a long way since Chuck was management. Do you consider
a Topic Guard to be necessary?
J
John Kelly
To Seebs it's all a mind game. But I'm old and grouchy and I don't have
time to play.
S
Seebs
Er, uhm. Actually, no, the problem is that you're a lunatic who has to
change posting names and addresses every so often because the old ones
get killfiled. And who steadfastly refuses to reason things through,
instead trying things at random, or grabbing random unrelated things
and asking whether they're related.
Uno, your approach to debugging is like doing geneaology by getting a
phone book, picking a name at random, then picking another name at random,
and asking them whether they are related. There's no method, no attempt
to apply available information to the task of finding new information.
Not really, no.
As is so often the case, people who think they are too busy to do something
right take more time than people who take the "extra" time to do it right.
Hint: If you seriously want to learn, you *MUST* play. There is no
effective way to learn any topic, any field of study, without play. If
you are not having fun when you are programming, you are not learning
as efficiently as someone who is having a great time at it, no matter
how much effort you put in.
The brain is built to learn -- and has well-designed tools for doing so.
Work with them, rather than against them.
-s
change posting names and addresses every so often because the old ones
get killfiled. And who steadfastly refuses to reason things through,
instead trying things at random, or grabbing random unrelated things
and asking whether they're related.
Uno, your approach to debugging is like doing geneaology by getting a
phone book, picking a name at random, then picking another name at random,
and asking them whether they are related. There's no method, no attempt
to apply available information to the task of finding new information.
Not really, no.
As is so often the case, people who think they are too busy to do something
right take more time than people who take the "extra" time to do it right.
Hint: If you seriously want to learn, you *MUST* play. There is no
effective way to learn any topic, any field of study, without play. If
you are not having fun when you are programming, you are not learning
as efficiently as someone who is having a great time at it, no matter
how much effort you put in.
The brain is built to learn -- and has well-designed tools for doing so.
Work with them, rather than against them.
-s
M
Malcolm McLean
It's a weird specification. 'Found in memory', OK, means we don't have
to write special code to trim strings in backing store. But that would
be assumed. "Whether data or garbage", you can't produce sensible
results from garbage. There's no system defined limit for a maximium
string size, except the range of a size_t. Whilst the last requirement
is possible to fulfil, it is fiddly, and most systems entirely
irrelevant (the program will surely segfault long before the size_t
index clocks rounds).
U
Uno
John said:
You're OP, and he's sitting on your thread saying that you're not sane.
There's always a dozen obnoxious Seebses in clc.
U
Uno
Seebs said:
So my programming is not up to snuff for you, right?
Maybe I'm asking about the things I don't get. I'm certain that I have
a much greater correspondence than you with the authors of C Unleashed,
which you use as an image.
Yeah Heathfield and I spend time in each other's killfiles.
Maybe I'm on a platform that is new to me.
Maybe I learn differently than you.
I can think of a million ways to insult you, all of them true.
Have a good night.
F
Francesco S. Carta
I'm not so sure I understand the reference you're making about Keith,
and actually, neither I am sure that you're really addressing the above
reply to me, although it seems to be so.
As you could read in the other thread-branch that descends from the
message you have just quoted from me, the issue about the presence of
EOVERFLOW in MinGW (and I suppose in GCC in general) should be already
ascertained, and the result should be that such a macro is not defined,
nowhere in the package it seems to be.
I
Ian Collins
EOVERFLOW is from POSIX, so it will be defined in the system headers
(rather than those supplied by the compiler) on any POSIX compliant system.
F
Francesco S. Carta
Fine, I think I have already understood that a conforming C
implementation is not required to provide such a macro.
What puzzles me is whether I give the impression that I didn't
understood the issue, or whether I give the impression that I'm even
remotely worried about it. I pointed out and discussed it just to the
advantage of the OP.
J
John Kelly
Seebs treats people like video game characters, then questions why not
everyone will tolerate it. He thinks his knowledge is so valuable that
it should excuse anything he says.
Common sense says, what goes around, comes around. Or if you understand
farming, you can only reap what you sow.
everyone will tolerate it. He thinks his knowledge is so valuable that
it should excuse anything he says.
Common sense says, what goes around, comes around. Or if you understand
farming, you can only reap what you sow.