trim whitespace, bullet proof version

[Geoff]

What's "better" depends. I like using this idiom:

if (trim(p) < 0)
printf ("we have a problem\n");

Using my way you can write

if(!trim(&p, &length)
printf("we have a problem")

Are Windows idioms superior to UNIX idioms?

Some are, some aren't. There's always a trade-off.

No.

I'm sure someone will spot it soon enough. It's so basic even K&R
talked about making sure to get it right, and it is a major design
flaw of getchar's interface. Of course, these days of Unicode we don't
have to worry about char anymore.

linux fork() is fast enough that many apps don't need threads. Someone
who needs threads can try writing trim_r().

Why pollute the system with thread safe and non-thread safe functions
that do identical things when you can design one thread-safe,
reentrant function for all environments?

Surely, you don't want to make the same mistake Microsoft did in their
libraries and have to build thread safe libs and non-thread safe libs
and then have to document them and tell programmers when to link them?

 

[John Kelly]

The obvious CLC answer to this is: What are threads?

My point, of course, is that once you go off-topic, anything is
possible (in terms of what are acceptable answers).

linux fork() is fast enough that many apps don't need threads. Someone
who needs threads can try writing trim_r().

Indeed. The previous poster was playing the usual CLC game - which is
to dream up some obscure scenario where there could, conceivably, be a
problem, then act as if YOU are a fucking idiot for not covering that
case.[/QUOTE]

That does happen in c.l.c. But in this case I think Geoff has some good
points. If the function worked threaded or not, that would be ideal.

My goal is to refine the non threaded version, to my satisfaction. If I
can complete that task, then I may consider what's required for adapting
it for threads. But I need to proceed one step at a time.

 

[Keith Thompson]

[...]

My position is this: It is not possible, given your specification
for trim(), to implement it in a way that avoids undefined behavior
unless you're able to control all possible callers. You can define
the circumstances in which its behavior is undefined, and define
the behavior in cases where it is defined. You cannot entirely
eliminate undefined behavior. Do you believe that you can? If not,
what *exactly* does "bullet proof" mean?

I appreciate your concern and welcome what help I can get. Right now
I'm focusing on one specific item.

I see that you haven't answered any of my questions.

void *memmove(void *dest, const void *src, size_t n);

It expects size_t for the length. It appears universally true that

typedef unsigned int size_t

Certainly not. Do you have a copy of the C standard?
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf is a
post-C99 draft available at no charge.

size_t is a typedef for some unsigned integer type, not necessarily
unsigned int.

Thus to me it makes no sense to call memmove with a negative value. Am
I wrong?

You *cannot* call memmove with a negative value for its third
parameter. If you call memmove(this, that, -1), the value -1 is
converted from int to size_t, so the value you're actually passing
is SIZE_MAX. (This is assuming the declaration is visible, which
it certainly should be.)

And again, you haven't answered any of my questions, and your
question about memmove() has nothing to do with what I wrote.

 

[John Kelly]

And again, you haven't answered any of my questions,

I started this thread, and it's not about you.

question about memmove() has nothing to do with what I wrote.

I welcome what help I can get, but so far, you have offered little. If
you really want to help, here is my immediate task:

As Ben pointed out, I need to use the lesser of SIZE_MAX or PTRDIFF_MAX
as my iteration limit.

If SIZE_MAX is not defined, I've learned how to compensate with:

# ifndef SIZE_MAX
# define SIZE_MAX ((size_t)-1)
# endif


However, on my Interix test platform, PTRDIFF_MAX is not defined, and
ptrdiff_t is signed. It's my understanding I can't use the same cast
trick with a signed type.

So what are my options for determining the maximum value representable
in a signed ptrdiff_t variable, when PTRDIFF_MAX is not defined?

 

[Geoff]

So what are my options for determining the maximum value representable
in a signed ptrdiff_t variable, when PTRDIFF_MAX is not defined?

It's implementation defined. See n1256 7.18(4) and 7.18.3(2).

In a standards compliant implementation PTRDIFF_MAX and PTRDIFF_MIN
are defined in <stdint.h>.

On a Win7 64 bit system the values are:
SIZE_MAX is ffffffffffffffff
Size of SIZE_MAX: 8
Size of ptrdiff_t: 8
INTMAX_MIN: 8000000000000000
INTMAX_MAX: 7fffffffffffffff
PTRDIFF_MIN: 8000000000000000
PTRDIFF_MAX: 7fffffffffffffff

In a 32 bit target, same source the values are:
SIZE_MAX is ffffffff
Size of SIZE_MAX: 4
Size of ptrdiff_t: 4
INTMAX_MIN: 8000000000000000
INTMAX_MAX: 7fffffffffffffff
PTRDIFF_MIN: 80000000
PTRDIFF_MAX: 7fffffff

Which I find very interesting.

 

[Ike Naar]

It appears universally true that

typedef unsigned int size_t

For some restricted notion of ``universally''.
On the unexceptional machine I'm using at the moment,
``unsigned int'' is a 32-bit type, and ``size_t'' is
an alias for ``unsigned long'', which is a 64-bit type.

 

[Keith Thompson]

I started this thread, and it's not about you.


I welcome what help I can get, but so far, you have offered little. If
you really want to help, here is my immediate task:

[snip]

Help you do what? I still don't know exactly what your "bullet proof"
version of trim() is supposed to do.

 

[Seebs]

I started this thread, and it's not about you.

And this, friends, is why you should always understand pathological
narcissism before trying to interact with the narcissist.

It's simply not part of his world that there would be any reason for
him to care what other people think or want, or what they are trying to
do.

I welcome what help I can get, but so far, you have offered little. If
you really want to help, here is my immediate task:

.... and here he is, ignoring useful advice, because your sole function
is to satisfy his whims.

You're sitting there babbling on about a "bridge" being "out", and he's
demanding that you tell him how to drive faster. This proves that you
are wrong, because he asked how to go faster before you mentioned the
bridge.

-s

 

[Moi]

Read up on pathological narcissism. It's not impossible to derive value
from responding to his posts, but you have to do so with a clear
understanding of what he's doing and why or it will be very frustrating.

He is a troll, Seebs. And a very good one.
My guess is it is one of the regulars trolling. (Kaz ?)

AvK

 

[John Kelly]

I welcome what help I can get, but so far, you have offered little. If
you really want to help, here is my immediate task:

[snip]

Help you do what?

What I just asked.

I still don't know exactly what your "bullet proof" version of trim()
is supposed to do.

Pompous pontificating posturing.

 

[John Kelly]

He is a troll, Seebs. And a very good one.
My guess is it is one of the regulars trolling. (Kaz ?)

I see Seebs is up to his usual ad hominem tricks and his fan club is
applauding.

I'll ask again, who can help me with this:

--------
However, on my Interix test platform, PTRDIFF_MAX is not defined, and
ptrdiff_t is signed. It's my understanding I can't use the same cast
trick with a signed type.

So what are my options for determining the maximum value representable
in a signed ptrdiff_t variable, when PTRDIFF_MAX is not defined?

 

[John Kelly]

It's implementation defined. See n1256 7.18(4) and 7.18.3(2).

In a standards compliant implementation PTRDIFF_MAX and PTRDIFF_MIN
are defined in <stdint.h>.

That seems to be C99. Interix seems to be C89.

 

[Kenny McCormack]

I welcome what help I can get, but so far, you have offered little. If
you really want to help, here is my immediate task:

[snip]

Help you do what?

What I just asked.

Boys, boys, boys!

Pompous pontificating posturing.

Indeed. Actually, I think Spinny said it best, when he described our
friend Kiki as a "corporate drone".

Also see:

http://redwing.hutman.net/~mreed/warriorshtm/android.htm

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch [sic] revelations of the childhood
traumas of the participants...

 

[Seebs]

He is a troll, Seebs. And a very good one.
My guess is it is one of the regulars trolling. (Kaz ?)

I don't think so, just because he posts elsewhere and has similar
behaviors. He makes grandiose claims, then declares all the systems
which are incompatible with them defective and uninteresting.

-s

 

[Seebs]

Pompous pontificating posturing.

A surprisingly accurate answer to the question.

-s

 

[Geoff]

That seems to be C99. Interix seems to be C89.

Indeed. But you seem to be mixing POSIX constants with your C89.

In your case I think I would choose to test that ptrdiff_t can
represent the signed difference between any two pointers in an array
of size from 0 to SIZE_MAX for your implementation and if SIZE_MAX is
not available, UINT_MAX.

 

[John Kelly]

Indeed. But you seem to be mixing POSIX constants with your C89.

On linux that's as natural as breathing. But I'll try and clean it up.

In your case I think I would choose to test that ptrdiff_t can
represent the signed difference between any two pointers in an array
of size from 0 to SIZE_MAX for your implementation

That seems to be tricky. None of the gurus touched my question.

and if SIZE_MAX is not available, UINT_MAX.

I learned how to derive SIZE_MAX with a macro, so that's covered. But
the signed ptrdiff_t is some tricky business.

 

[Ian Collins]

That seems to be C99. Interix seems to be C89.

It's generally a good idea to start out knowing what language you are
compiling.

 

[John Kelly]

It's generally a good idea to start out knowing what language you are
compiling.

With trim() I'm aiming for least common denominator. C89 should be
upward compatible I presume.

 

[John Kelly]

Since your new version doesn't modify *ts one could use parameter
list (char *ts) rather than (char **ts) [or could use (char const *ts)
if you add a (char *)ts cast in memmove call].

Done.

However, the pointer is constant, but the string data is not. So this
is what I used:

trim (char *const ts)