469,929 Members | 1,557 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,929 developers. It's quick & easy.

independent string functions

There is one little static C library to manage the serial number and
unlock key for my application. Today it is compiled with Microsoft
VC6 and linked into both VC6 modules and VS2005 modules. It is not a
lot of code, but obviously it is very important code that is used all
over:

VS2005: used in a C++/CLI module for .Net
VS2005: Apache module
VC6: DLL that is called by the installation program

There are two things I need to do:

1: Upgrade the VC6 module to VS2005.
2: Prepare this static library to go cross platform.

As it stands now the ONLY functions the library is using from the CRT
are string manipulation functions, the library does not allocate any
memory right now and is pure C. I am looking for an alternative to
the standard string functions, something I can simply include in this
library so that it is 100% self contains and won’t run into issues
when I compile it with VS2005 (later VS2008) nor with the Linux and
Mac C/C++ compilers.

Cartoper

P.S. I know .Net is not cross platform, so that is going to be
totally rewritten, too.
Jun 27 '08 #1
15 1598
Cartoper wrote:
There is one little static C library to manage the serial number and
unlock key for my application. Today it is compiled with Microsoft
VC6 and linked into both VC6 modules and VS2005 modules. It is not a
lot of code, but obviously it is very important code that is used all
over:

VS2005: used in a C++/CLI module for .Net
VS2005: Apache module
VC6: DLL that is called by the installation program

There are two things I need to do:

1: Upgrade the VC6 module to VS2005.
2: Prepare this static library to go cross platform.

As it stands now the ONLY functions the library is using from the CRT
are string manipulation functions, the library does not allocate any
memory right now and is pure C. I am looking for an alternative to
the standard string functions, something I can simply include in this
library so that it is 100% self contains and won’t run into issues
when I compile it with VS2005 (later VS2008) nor with the Linux and
Mac C/C++ compilers.

Cartoper

P.S. I know .Net is not cross platform, so that is going to be
totally rewritten, too.
I can give you the source code for any string library function.
Then your library would be self contained.
For pricing address the mail address below (in the .sig)

Alternatively you could go fishing for the source code of those
functions, they are not very difficult to find.

You can start at

www.google.com/codesearch.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jun 27 '08 #2
Cartoper wrote:
As it stands now the ONLY functions the library is using from the CRT
are string manipulation functions, the library does not allocate any
memory right now and is pure C. I am looking for an alternative to
the standard string functions, something I can simply include in this
library so that it is 100% self contains and won’t run into issues
when I compile it with VS2005 (later VS2008) nor with the Linux and
Mac C/C++ compilers.
Why not using the string functions the standard C library provides? What
issue do you expect to run into, when using stands C string functions on
implementations that do (claim to) provide a standard comformant C compiler
whith a standard conformant C library? After all that is what protable
programming is all about, isn't it?

Bye, Jojo
Jun 27 '08 #3
Cartoper <ca******@gmail.comwrites:
There is one little static C library to manage the serial number and
unlock key for my application. Today it is compiled with Microsoft
VC6 and linked into both VC6 modules and VS2005 modules. It is not a
lot of code, but obviously it is very important code that is used all
over:

VS2005: used in a C++/CLI module for .Net
VS2005: Apache module
VC6: DLL that is called by the installation program

There are two things I need to do:

1: Upgrade the VC6 module to VS2005.
2: Prepare this static library to go cross platform.

As it stands now the ONLY functions the library is using from the CRT
are string manipulation functions, the library does not allocate any
memory right now and is pure C. I am looking for an alternative to
the standard string functions, something I can simply include in this
library so that it is 100% self contains and won’t run into issues
when I compile it with VS2005 (later VS2008) nor with the Linux and
Mac C/C++ compilers.
I must be missing something obvious, but why can't you just keep using
C's string functions? Your library is in C, so obviously you can link
C code into all the desired targets. I can't see why you can't also
just link against the C library.

Anyway, if you list the ones that the library uses, I am sure people
here can post versions written in portable C. The only hard ones are
the scanf and printf family. You might want to say what formats you
actually use since that can make a difference as to how hard a
re-write it is.

Obviously, there are open-source versions available, so you'll also
have to say what licences are acceptable.

--
Ben.
Jun 27 '08 #4
Cartoper wrote:
I am looking for an alternative to
the standard string functions, something I can simply include in this
library so that it is 100% self contains and won’t run into issues
when I compile it with VS2005 (later VS2008) nor with the Linux and
Mac C/C++ compilers.
http://www.mindspring.com/~pfilandr/C/library/str_ing.h
http://www.mindspring.com/~pfilandr/C/library/str_ing.c

--
pete
Jun 27 '08 #5
Cartoper wrote:
[...]
As it stands now the ONLY functions the library is using from the CRT
are string manipulation functions, the library does not allocate any
memory right now and is pure C. I am looking for an alternative to
the standard string functions, something I can simply include in this
library so that it is 100% self contains and won’t run into issues
when I compile it with VS2005 (later VS2008) nor with the Linux and
Mac C/C++ compilers.
First, verify that the "issues" you're worried about
are actually worth worrying about. Any hosted C environment
will provide all the functions declared in <string.h>, so
you shouldn't need to write replacements.

If you do in fact have "issues" -- maybe you're worried
about someone substituting his own strcmp() for the system-
provided one and somehow using it to subvert your licensing
scheme? -- Then writing replacements for the functions you
actually need should be straightforward. Most <string.h>
functions are not complicated, and their only "magic" is that
the system-provided versions are often very highly optimized
for the machines they run on. If you're willing to forgo the
speed advantages, just write plain-C work-alikes. Don't call
them strcmp(), strcpy(), and so on, though, or you're likely
to create "issues" where there were none before. Here's an
example to get you started:

char *xstrchr(const char *s, int c) {
for ( ; *s != c; ++s) {
if (*s == '\0')
return NULL;
}
return (char*)s;
}

Aside: You may be able to find pre-written implementations
for these functions floating around on the Net somewhere, but
pay attention to their licensing terms. Since your goal is to
use these functions with your application's "serial number and
unlock key," using GPL'ed code might be self-defeating ...

--
Eric Sosman
es*****@ieee-dot-org.invalid
Jun 27 '08 #6
On Jun 20, 9:21*am, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
I must be missing something obvious, but why can't you just keep using
C's string functions? *Your library is in C, so obviously you can link
C code into all the desired targets. *I can't see why you can't also
just link against the C library.
Yea, the issue is with Microsoft compilers. As of VS2005 it has
warnings all over the place about using strcpy, strcat and wants you
to use the safer strcpy_s and strcat_s. Also with Microsoft's stuff,
there are hoops to jump though with VS2005 when dealing with the
runtime that I simply don't want to have to contend with in this
little static library.
Anyway, if you list the ones that the library uses, I am sure people
here can post versions written in portable C. *The only hard ones are
the scanf and printf family. *You might want to say what formats you
actually use since that can make a difference as to how hard a
re-write it is.
I am not using sprintf or sscanf, just the standard strcpy, strcat,
strlen, etc.
Obviously, there are open-source versions available, so you'll also
have to say what licences are acceptable.
GPL won't work because the source is closed, for obvious reasons, I
need something that can stay closed source. This IS the code that
does the decryption of the unlock key, so it is sort of important to
keep it closed source;)
Jun 27 '08 #7
On Jun 20, 9:27*am, pete <pfil...@mindspring.comwrote:
http://www.mindspring.com/~pfilandr/C/library/str_ing.h
http://www.mindspring.com/~pfilandr/C/library/str_ing.c
Pete,

I think that is perfect, thanks!!!!!!!!!!!!!!!

Cartoper

Jun 27 '08 #8
Eric Sosman wrote:
Cartoper wrote:
>[...]
As it stands now the ONLY functions the library is using from the CRT
are string manipulation functions, the library does not allocate any
memory right now and is pure C. I am looking for an alternative to
the standard string functions, something I can simply include in this
library so that it is 100% self contains and won’t run into issues
when I compile it with VS2005 (later VS2008) nor with the Linux and
Mac C/C++ compilers.

First, verify that the "issues" you're worried about
are actually worth worrying about. Any hosted C environment
will provide all the functions declared in <string.h>, so
you shouldn't need to write replacements.

If you do in fact have "issues" -- maybe you're worried
about someone substituting his own strcmp() for the system-
provided one and somehow using it to subvert your licensing
scheme? -- Then writing replacements for the functions you
actually need should be straightforward. Most <string.h>
functions are not complicated, and their only "magic" is that
the system-provided versions are often very highly optimized
for the machines they run on. If you're willing to forgo the
speed advantages, just write plain-C work-alikes. Don't call
them strcmp(), strcpy(), and so on, though, or you're likely
to create "issues" where there were none before. Here's an
example to get you started:

char *xstrchr(const char *s, int c) {
for ( ; *s != c; ++s) {
if (*s == '\0')
return NULL;
}
return (char*)s;
}
I can't imagine what difference the conversion might make,
but the standards describe the comparison in strchr
as being more like

(*s != (char)c)

--
pete
Jun 27 '08 #9
Cartoper wrote:
On Jun 20, 9:27 am, pete <pfil...@mindspring.comwrote:
>http://www.mindspring.com/~pfilandr/C/library/str_ing.h
http://www.mindspring.com/~pfilandr/C/library/str_ing.c

Pete,

I think that is perfect, thanks!!!!!!!!!!!!!!!

Cartoper
You're welcome. I hope it works out.
If stddef.h turns out not to be available,
then you can replace all instances of
size_t
with
long unsigned
and all instances of
NULL
can be replaced with
0
and then the code will be in the C language proper
(the part of the C programming language
which is described in the "Language" section of the standard).

--
pete
Jun 27 '08 #10
Cartoper wrote:
On Jun 20, 9:21 am, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
>I must be missing something obvious, but why can't you just keep using
C's string functions? Your library is in C, so obviously you can link
C code into all the desired targets. I can't see why you can't also
just link against the C library.

Yea, the issue is with Microsoft compilers. As of VS2005 it has
warnings all over the place about using strcpy, strcat and wants you
to use the safer strcpy_s and strcat_s.
Find out how to tell the stupid compiler to shut up about
the bogus warnings, or learn to ignore them, or find a better
compiler. (It was a Microsoft compiler that once warned me I
risked loss of precision in `float f = 0.0;' ...)
>Anyway, if you list the ones that the library uses, I am sure people
here can post versions written in portable C. The only hard ones are
the scanf and printf family. You might want to say what formats you
actually use since that can make a difference as to how hard a
re-write it is.

I am not using sprintf or sscanf, just the standard strcpy, strcat,
strlen, etc.
I'm not familiar with this etc() function; what does it do?
If it does the same things as strcspn(), say, you should be able
to write it yourself in a couple of minutes -- but if it does
what strerror() or strxfrm() or strcoll() do then your job will
be harder.
GPL won't work because the source is closed, for obvious reasons, I
need something that can stay closed source. This IS the code that
does the decryption of the unlock key, so it is sort of important to
keep it closed source;)
Then write it yourself or be prepared to pay for it. Jacob
has already extended a commercial offer; consider it.

--
Er*********@sun.com
Jun 27 '08 #11
pete wrote:
Eric Sosman wrote:
>[...] Here's an
example to get you started:

char *xstrchr(const char *s, int c) {
for ( ; *s != c; ++s) {
if (*s == '\0')
return NULL;
}
return (char*)s;
}

I can't imagine what difference the conversion might make,
but the standards describe the comparison in strchr
as being more like

(*s != (char)c)
Good catch; thanks. (That's what I get for coding
before coffee-ing.)

--
Er*********@sun.com
Jun 27 '08 #12
Eric Sosman wrote:
pete wrote:
>Eric Sosman wrote:
>>[...] Here's an
example to get you started:

char *xstrchr(const char *s, int c) {
for ( ; *s != c; ++s) {
if (*s == '\0')
return NULL;
}
return (char*)s;
}

I can't imagine what difference the conversion might make,
but the standards describe the comparison in strchr
as being more like

(*s != (char)c)

Good catch; thanks. (That's what I get for coding
before coffee-ing.)
That's according to the old standard and the current standard.

According to n1256.pdf, the strchr comparison will be more like

(*(unsigned char *)s != (char)c)

--
pete
Jun 27 '08 #13
pete wrote:
Eric Sosman wrote:
>pete wrote:
>>Eric Sosman wrote:
[...] Here's an
example to get you started:

char *xstrchr(const char *s, int c) {
for ( ; *s != c; ++s) {
if (*s == '\0')
return NULL;
}
return (char*)s;
}

I can't imagine what difference the conversion might make,
but the standards describe the comparison in strchr
as being more like

(*s != (char)c)

Good catch; thanks. (That's what I get for coding
before coffee-ing.)

That's according to the old standard and the current standard.

According to n1256.pdf, the strchr comparison will be more like

(*(unsigned char *)s != (char)c)
Okay, I looked up this "Committee Draft," and it seems
they're considering a change in the way character comparisons
work in the library functions. Unless I'm mistaken, the change
will be drastic for machines with signed char. Assuming for
example CHAR_MIN<0,

char pos_one[] = "\0"; /* two bytes */
char neg_one[] = "\0"; /* two bytes */
pos_one[0] += 1; /* now pos_one[0] 0 */
neg_one[0] -= 1; /* now neg_one[0] < 0 */
int c = strcmp(neg_one, pos_one);

.... then the current Standard requires c<0, while the proposed
draft requires c>0. Q1: Is my analysis right? Q2: If so, do
you think the draft will be adopted?

--
Eric Sosman
es*****@ieee-dot-org.invalid
Jun 27 '08 #14
Eric Sosman wrote:
pete wrote:
>Eric Sosman wrote:
>>pete wrote:
Eric Sosman wrote:
[...] Here's an
example to get you started:
>
char *xstrchr(const char *s, int c) {
for ( ; *s != c; ++s) {
if (*s == '\0')
return NULL;
}
return (char*)s;
}

I can't imagine what difference the conversion might make,
but the standards describe the comparison in strchr
as being more like

(*s != (char)c)

Good catch; thanks. (That's what I get for coding
before coffee-ing.)

That's according to the old standard and the current standard.

According to n1256.pdf, the strchr comparison will be more like

(*(unsigned char *)s != (char)c)

Okay, I looked up this "Committee Draft," and it seems
they're considering a change in the way character comparisons
work in the library functions. Unless I'm mistaken, the change
will be drastic for machines with signed char. Assuming for
example CHAR_MIN<0,

char pos_one[] = "\0"; /* two bytes */
char neg_one[] = "\0"; /* two bytes */
pos_one[0] += 1; /* now pos_one[0] 0 */
neg_one[0] -= 1; /* now neg_one[0] < 0 */
int c = strcmp(neg_one, pos_one);

... then the current Standard requires c<0, while the proposed
draft requires c>0. Q1: Is my analysis right?
No.

strchr, and the related strrchr,
are unusual in that their descriptions
are the only two places in either C standard
that contain the phrase "(converted to a char)".

strcmp is still the same as it has been since C89.
ISO/IEC 9899: 1990

7.11.4 Comparison functions
The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp
is determined by the sign of the difference
between the values of the first pair of characters
(both interpreted as unsigned char)
that differ in the objects being compared.

--
pete
Jun 27 '08 #15
On 20 Jun, 14:31, Cartoper <carto...@gmail.comwrote:
On Jun 20, 9:21*am, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
I must be missing something obvious, but why can't you just keep using
C's string functions? *Your library is in C, so obviously you can link
C code into all the desired targets. *I can't see why you can't also
just link against the C library.
me too
Yea, the issue is with Microsoft compilers. *As of VS2005 it has
warnings all over the place about using strcpy, strcat and wants you
to use the safer strcpy_s and strcat_s.
it is pretty to suppress this error (I consider it an error
in the compiler not your program).

>*Also with Microsoft's stuff,
there are hoops to jump though with VS2005 when dealing with the
runtime that I simply don't want to have to contend with in this
little static library.
what hoops? Can't you ifdef it out?

#ifdef WIN32
for (i = 0; i < hoop_count; i++)
jump_through_hoop (i);
#endif

Anyway, if you list the ones that the library uses, I am sure people
here can post versions written in portable C. *The only hard ones are
the scanf and printf family. *You might want to say what formats you
actually use since that can make a difference as to how hard a
re-write it is.

I am not using sprintf or sscanf, just the standard strcpy, strcat,
strlen, etc.
Obviously, there are open-source versions available, so you'll also
have to say what licences are acceptable.

GPL won't work because the source is closed, for obvious reasons, I
need something that can stay closed source. *This IS the code that
does the decryption of the unlock key, so it is sort of important to
keep it closed source;)
I still think the best solution is to just use the standard
library functions.
--
Nick Keighley
Jun 27 '08 #16

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Binny V A | last post: by
2 posts views Thread by sprotty | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.