Cipher Lab / Syntech

[Cawas]

Cipher Lab produces some terminals to collect data where we can
program using one implementation of plain C which I believe to be ANSI
C89 compatible, although not fully. They have their on set of
libraries as well, but all in all, it's basic C we're talking about.

Ok, this is my first time on lots of things. I've never been to
usenet, and I'm not much an expert of Google Groups, or IRC, and
similar forums-thingies, with the exception of PHPBB / VBulletin PHP
forums system, which are pretty simple content-wise.

So I'm not sure I'm posting this in the right place, or if I even
should be doing it here. I did my research but it'll never be as good
as just trying it out.

Also I did not and wish not to look for this kind of information on
the owner's site. I believe they won't have much support, and
certainlly not as deep as I want.

I'm also starting working with C this year, and getting the depth of
it as well just now (although I'm a little familiar with it since
2000). Hopefully, at very least, I'll have some documentation done
alone by myself, if nobody joins.

Introductions aside, I do have lots of questions and I'd like to know
if by any chance someone knows of a more specific place where I could
find people that are programming for C and those terminals from Cipher
Lab that wish to share knowledge, discuss over programming, etc.

Particularly, I'd love to know if someone could sucessfully use any
well known string library on it, such as Paul Hsieh's bstring (
http://bstring.sourceforge.net ), although I doubt it. And I know for
experience that it would be nice to share some custom made libraries
to solve lots of troubles on those terminals, since I've been
painfully building one myself, from scratch.

Anyway, I'll be organizing and trying to isolate some problems I'm
getting with the terminal and post them following in here, together
with some functions I've been using, and may be of some use for
someone, even if just as basic learning purpose, since I am (or at
least feel like) still at basics myself.

The next "topics" I'll try to bring are:
1. strings - I think 90% of all troubles I'm having are from trying to
manipulate them. A good simple workaround library, which does not use
malloc, would be greatly appreciated. But maybe I'll just finish my
own soon enough.

2. extern volatile unsigned long sys_msec - not the sys_msec itself,
rather trying to use it with other "unsigned long" variables. I've
tried to isolate this problem with no success yet, so I'm even more
intrigued in why I'm getting it in my program, which must have around
5000 lines.

3. void OSTimeDly (unsigned long ticks) - when creating a task with
OSTaskCreate, it will only be activated by an OSTimeDly. This can get
really messy to use, specially when mixing it with getchar.

4. stdarg.h - it does not have va_copy, but I'm not having an issue
with that. Although I'd love to see an implementation of va_copy since
I have no idea how to write it, my problem here is on using it to
create my own vprintf. I could create a "dprintf" that works just
fine, but I've wanted to expand it, making a rdprintf that would use
dprintf. For that, I need to create a vdprintf, and that's where I
can't go beyond.

5. speeds issues - apparently, the most demanding is to print and
clear the screen. I've build a function to list the entries from the
DBF files, but it's quite slow to scroll down. This is the only place
where I've seem speed as an issue, and I'm still trying to figure out
a way to make it smooth, although I've managed to make it
satisfactory.

6. select queries - this is probably just a "dream", but I did wish to
be able to filter the above list with something at least similar to a
SQL. For now, I just can't filter it at all. Maybe it never will.


And that's way more than enough for now!

 

[Flash Gordon]

Cawas wrote, On 15/05/07 21:12:

Cipher Lab produces some terminals to collect data where we can
program using one implementation of plain C which I believe to be ANSI
C89 compatible, although not fully. They have their on set of
libraries as well, but all in all, it's basic C we're talking about.

We can't help you with the vagaries of your particular C
implementations, but we can help you with standard C (ISO or ANSI, any
version) and with pre-ANSI C (i.g. K&R C).

Particularly, I'd love to know if someone could sucessfully use any
well known string library on it, such as Paul Hsieh's bstring (
http://bstring.sourceforge.net ), although I doubt it.

Paul posts here, and I'm sure he will be prepared to help you with his
library. He can also point you at the best place to discus it.

> And I know for
experience that it would be nice to share some custom made libraries
to solve lots of troubles on those terminals, since I've been
painfully building one myself, from scratch.

Those third party libraries are not topical here either.

The next "topics" I'll try to bring are:
1. strings - I think 90% of all troubles I'm having are from trying to
manipulate them. A good simple workaround library, which does not use
malloc, would be greatly appreciated. But maybe I'll just finish my
own soon enough.

Any "simple" library is likely to use malloc under the hood.

2. extern volatile unsigned long sys_msec - not the sys_msec itself,
rather trying to use it with other "unsigned long" variables. I've
tried to isolate this problem with no success yet, so I'm even more
intrigued in why I'm getting it in my program, which must have around
5000 lines.

What is your problem with it? We are not mind readers! I know that no
one here is a mind reader because I have read everyone's minds to check!

3. void OSTimeDly (unsigned long ticks) - when creating a task with
OSTaskCreate, it will only be activated by an OSTimeDly. This can get
really messy to use, specially when mixing it with getchar.

That is non-standard so we cannot help you with it.

4. stdarg.h - it does not have va_copy, but I'm not having an issue
with that.

Not surprising since it was only added to the standard in 1999, and most
compilers do not support this "new" standard.

> Although I'd love to see an implementation of va_copy since
I have no idea how to write it,

You cannot write it portably, which is probably why it was added to the
standard. Non-portable tricks to implement it are not topical here.

> my problem here is on using it to
create my own vprintf. I could create a "dprintf" that works just
fine, but I've wanted to expand it, making a rdprintf that would use
dprintf. For that, I need to create a vdprintf, and that's where I
can't go beyond.

Without more information on what you are trying to do it is hard to
offer advice. With more details we probably can help with this.

5. speeds issues - apparently, the most demanding is to print and
clear the screen. I've build a function to list the entries from the
DBF files, but it's quite slow to scroll down. This is the only place
where I've seem speed as an issue, and I'm still trying to figure out
a way to make it smooth, although I've managed to make it
satisfactory.

The C standard knows nothing about "DBF files" or scrolling, so this is
not topical here.

6. select queries - this is probably just a "dream", but I did wish to
be able to filter the above list with something at least similar to a
SQL. For now, I just can't filter it at all. Maybe it never will.

There are SQL libraries you could investigate, such as sqlite, but they
are not topical here.

 

[Richard]

Cawas wrote, On 15/05/07 21:12:

We can't help you with the vagaries of your particular C
implementations, but we can help you with standard C (ISO or ANSI, any
version) and with pre-ANSI C (i.g. K&R C).



Paul posts here, and I'm sure he will be prepared to help you with his
library. He can also point you at the best place to discus it.


Those third party libraries are not topical here either.



Any "simple" library is likely to use malloc under the hood.


What is your problem with it? We are not mind readers! I know that no
one here is a mind reader because I have read everyone's minds to
check!


That is non-standard so we cannot help you with it.


Not surprising since it was only added to the standard in 1999, and
most compilers do not support this "new" standard.


You cannot write it portably, which is probably why it was added to
the standard. Non-portable tricks to implement it are not topical
here.


Without more information on what you are trying to do it is hard to
offer advice. With more details we probably can help with this.


The C standard knows nothing about "DBF files" or scrolling, so this
is not topical here.


There are SQL libraries you could investigate, such as sqlite, but
they are not topical here.

Do you realise you said "off topic" 7 times? Is this a new record?

Why bother replying? It's a waste of every ones time. Probably least of
all yours. Don't you have enough "c.l.c pedant" medals by now?

 

[Richard Heathfield]

Richard said:

Do you realise you said "off topic" 7 times? Is this a new record?

Why bother replying?

So that the OP will know which parts of his query are topical and which
not, so that he will not waste his time and ours in looking here for
answers which he needs to seek elsewhere.

It's a waste of every ones time.

No, it's an attempt to /save/ everyone's time. If you had thought this
through properly, you would have realised that you have no point
whatsoever and would not have bothered to reply, and /that/ would have
saved everyone's time, too.

 

[Cawas]

Thanks for your prompt reply, Flash! I really was not counting with
such attention in any answer.

If it were not for being such a peculiar issue I would be having no
problems finding answers in the groups. I'm really not much a fan of
posting repeated subjects. I see what you mean about lots of my
questions being non-topics in here, but if I want to use google groups
for this topic, what should I do? Create a new group under
comp.lang.c ? I was hoping here would be a good place to ask for
directions and instead of being vague by stopping at the first
paragraphs, I've wanted to give specific details about it.

I have not posted code snippets exactly because I was not sure this
was the proper place to discuss them. And also because I need to build
the snippets to work out of context. I am not asking for any help on
the codes just yet, I was hoping that was clear. I just organized that
list for myself, and as samples of what I'm looking for, as Richard
pointed out.

Well,
The "simple" library without malloc is needed because I was told
malloc is not well implemented on this terminal, and should not be
used. I was actually using malloc in my program before, without any
problems, but I removed all of them under that advice, and I'd like to
keep it safe and go without it because I'm not sure why malloc could
be such an issue for the terminal. But even using just static memory
the regular C "string" is a pain, to mention the less.

As for Paul, I would not bother him with this. He seems to enjoy
problems which are much more complex and global, and I can't imagine
myself talking at his level of computing understanding in general. I
would be just boring for him. I cited his lib, though, because I've
realised the effort he put behind it, and it would be nice to have
such lib that I could use and learn from using it.

About he item 2, it was actually the reason I've wanted to see if I
could find some community which would share problems about this
specific C. Looking through its libraries, it says its copyrighted to
Toshiba, 1994.

Anyway, since you seem eager to help, I'm expanding items 2 and 4,
hoping they do belong here.

And thanks again!

------
2. unsigned long issue ?

I'm still trying to reproduce the actual problem I'm having, but
meanwhile I'll just describe it here. The following code works fine,
if compiled with syntech's CC900.EXE which comes with the terminal,
for the model CPT8100:

In case you wonder, the 8100lib.h implements printf, and maybe all of
stdio.h (I haven't checked it).

#include <ucos.h>
#include <8100lib.h>

#define DELAY 5000 /* ms */

unsigned long sysmsec (void) { return sys_msec * 5; }

void foo (const unsigned long delay) {
const unsigned long final_msec = sysmsec() + delay;
while (sysmsec() < final_msec) {
gotoxy(0, 7);
printf("%ld,%ld", sysmsec()+delay, sysmsec());
}
}

void bar (void) {
foo(DELAY);
}

int main (void) {
gotoxy(0, 0);
printf("%ld", sysmsec());
bar();

gotoxy(0, 1);
printf("%ld", sysmsec());
foo(DELAY);

return 0;
}

In practice, I have just "main" in a separated file (although I'm just
using include to concatanate all separated files, instead of compiling
them separatedly), and if I try to call the equivalent of foo(DELAY)
the delay inside foo comes with a random gigantic value, while the
equivalent of bar(), which has also just that one line, works just
fine.

The actual functions basically have more parameters. While s_read_com
also do something, ds_read_com, the bar equivalent, just have more
parameters. I hope it's safe to ignore ds_read_com implementation:

int ds_read_com (int nPort, char* buff, size_t s, const char* cterm,
const unsigned char key, const unsigned long delay);

int s_read_com (int nPort, char* buff, size_t s, const char* cterm,
const unsigned char key) {
return ds_read_com(nPort, buff, s, cterm, key, DELAY_READ_COM);
}

I'll leave this here for now, but I think I'll have to solve it
myself. Right now I'm doing a lot of debug on it, and I'll post here
whenever I get it fixed, specially if I identify why it happens. I
think I'm making some progress.


------
4. stdarg.h
For some reason, I can use vsprintf, but not vprintf, so I did this:

int __CDECL vprintf (const char *format, va_list arg) {
char prt[200+1];
vsprintf(prt, format, arg);
return puts(prt);
}

Keep in mind malloc is not an option. That works, but I wonder what
would be a better way to write it.

I really thought that something similar to the following
implementation of dprintf and rdprintf was quite logical to deduce,
but it never hurts to give my practical example:

int dprintf (int mode, const char* fmt, ...) {
va_list arglist;
int result;
int oldmode;
if (mode >= 0) {
oldmode = GetVideoMode();
SetVideoMode(mode);
}
va_start(arglist, fmt);
result = vprintf(fmt, arglist);
va_end(arglist);
if (mode >= 0) SetVideoMode(oldmode);
return result;
}

int rdprintf (int mode, const char* fmt, ...) {
va_list arglist;
int result;
int oldx = wherex();
int oldy = wherey();
int oldcursor = GetCursor();
SetCursor(CURSOR_OFF);

va_start(arglist, fmt);
result = vdprintf(mode, fmt, arglist);
va_end(arglist);

gotoxy(oldx, oldy);
SetCursor(oldcursor);
return result;
}


The "mode" could be anything else and, in fact, I have many more
parameters in dprintf. In case you wonder the letters meanings, d is
for display, and r is for recover, because the first is for
manipulating some display options in the terminal, and the second is
for also recovering the previous options.

Now, how would I write vdprintf? I am just hoping I don't need to use
va_arg and make an interpreter for fmt, because I can imagine that
solution, but I can also imagine how big it would be. And I also
realize I could just re-write dprintf inside rdprintf, but that would
be bad for further updates. It would be bad coding with really small
price to pay, but even then I rather avoid it.

 

[Flash Gordon]

Cawas wrote, On 16/05/07 16:03:

Thanks for your prompt reply, Flash! I really was not counting with
such attention in any answer.

If it were not for being such a peculiar issue I would be having no
problems finding answers in the groups. I'm really not much a fan of
posting repeated subjects. I see what you mean about lots of my
questions being non-topics in here,

Making a mistake is fine.

> but if I want to use google groups
for this topic, what should I do?

Firstly, this is not Google Groups. Google Groups is merely one
interface on to a far larger thing called Usenet, something that existed
before Google existed.

> Create a new group under
comp.lang.c ?

No. There is a procedure for creating groups, a procedure that has
nothing to do with Google, and I doubt that you would succeed.

I suggest you look for mailing lists dedicated to your system.

Also, if your system is an embedded system then comp.arch.embedded may
be able to offer some assistance.

Well,
The "simple" library without malloc is needed because I was told
malloc is not well implemented on this terminal, and should not be
used. I was actually using malloc in my program before, without any
problems, but I removed all of them under that advice, and I'd like to
keep it safe and go without it because I'm not sure why malloc could
be such an issue for the terminal. But even using just static memory
the regular C "string" is a pain, to mention the less.

First rule of optimisation, don't do it. If the performance of your
application was fine with malloc and that was the clearest way to write
it you should have stuck with it. Something I've learnt is that many of
the "don't do this because it is inefficient" suggestions are no longer
relevant because technology has moved on. Also, it is easier to speed up
a working and clearly written program than to get a fast but hard to
read program working correctly.

As for Paul, I would not bother him with this. He seems to enjoy

<snip>

You might be surprised. He has certainly been prepared to halp on far
simpler things.

About he item 2, it was actually the reason I've wanted to see if I
could find some community which would share problems about this
specific C. Looking through its libraries, it says its copyrighted to
Toshiba, 1994.

With that date I would have hoped that it would conform fully to C89,
the standard released by ANSI in 1989.

Anyway, since you seem eager to help, I'm expanding items 2 and 4,
hoping they do belong here.

And thanks again!

------
2. unsigned long issue ?

I'm still trying to reproduce the actual problem I'm having, but
meanwhile I'll just describe it here. The following code works fine,
if compiled with syntech's CC900.EXE which comes with the terminal,
for the model CPT8100:

In case you wonder, the 8100lib.h implements printf, and maybe all of
stdio.h (I haven't checked it).

From the sounds of this comp.arch.embedded may well be a better place
for initial questioning.

#include <ucos.h>
#include <8100lib.h>

#define DELAY 5000 /* ms */

unsigned long sysmsec (void) { return sys_msec * 5; }

void foo (const unsigned long delay) {
const unsigned long final_msec = sysmsec() + delay;
while (sysmsec() < final_msec) {
gotoxy(0, 7);
printf("%ld,%ld", sysmsec()+delay, sysmsec());
}
}

void bar (void) {
foo(DELAY);
}

int main (void) {
gotoxy(0, 0);
printf("%ld", sysmsec());
bar();

gotoxy(0, 1);
printf("%ld", sysmsec());
foo(DELAY);

return 0;
}

In practice, I have just "main" in a separated file (although I'm just
using include to concatanate all separated files, instead of compiling
them separatedly), and if I try to call the equivalent of foo(DELAY)
the delay inside foo comes with a random gigantic value, while the
equivalent of bar(), which has also just that one line, works just
fine.

<snip>

I'm guessing that the problem is that you do not have a prototype in
scope and you need one. When splitting a project in to multiple files it
is normal to do something like:

/* foo.h */
#ifndef H_FOO
#define H_FOO

unsigned long foo(unsigned long x);

#endif

/* foo.c */
#include "foo.h"

unsigned long foo(unsigned long x)
{
return x * 3;
}

/* main.c */
#include "foo.h"
....

This way the compiler always knows the correct types of everything.
Otherwise it is required to make assumptions that are not always true.

------
4. stdarg.h
For some reason, I can use vsprintf, but not vprintf, so I did this:

int __CDECL vprintf (const char *format, va_list arg) {
char prt[200+1];
vsprintf(prt, format, arg);
return puts(prt);
}

Keep in mind malloc is not an option. That works, but I wonder what
would be a better way to write it.

Why can you not use vprintf? My first guess would be that you were using
it incorrectly, and solving that problem would be better than working
around it.

I really thought that something similar to the following
implementation of dprintf and rdprintf was quite logical to deduce,
but it never hurts to give my practical example:

int dprintf (int mode, const char* fmt, ...) {
va_list arglist;
int result;
int oldmode;
if (mode >= 0) {
oldmode = GetVideoMode();
SetVideoMode(mode);
}
va_start(arglist, fmt);
result = vprintf(fmt, arglist);
va_end(arglist);
if (mode >= 0) SetVideoMode(oldmode);
return result;
}

<snip>

Nothing looks wrong in the above, assuming your use of non-standard
functions is correct and you have included the correct headers for all
of the functions.

The "mode" could be anything else and, in fact, I have many more
parameters in dprintf.

<snip>

Here is a major problem. If you do not provide a small complete example
that actually shows the problem we don't stand much chance of diagnosing
it. Consider that if you do not know what is causing the problem then
you do not know it is in part of the code you are not showing. You may
also find that in cutting the program down to a failing example small
enough to post you actually find the problem.

This advice applies to any group you are posting to, including
comp.arch.embedded which I *think* might be an appropriate group.

 

[Keith Thompson]

Thanks for your prompt reply, Flash! I really was not counting with
such attention in any answer.

When posting a followup, you should usually quote the relevant parts
of the parent article. See most of the articles here for examples.
See also <http://cfaj.freeshell.org/google/>. In this particular
case, your followup is probably clear enough without quoted context,
but keep it in mind for future postings.

If it were not for being such a peculiar issue I would be having no
problems finding answers in the groups. I'm really not much a fan of
posting repeated subjects. I see what you mean about lots of my
questions being non-topics in here, but if I want to use google groups
for this topic, what should I do? Create a new group under
comp.lang.c ? I was hoping here would be a good place to ask for
directions and instead of being vague by stopping at the first
paragraphs, I've wanted to give specific details about it.

You need to be aware that Google Groups is *not* Usenet. Usenet is a
distributed discussion forum that has existed for several decades.
Google Groups is, among other things, an archive of Usenet and a
(sometimes rather inconvenient) interface to it. comp.lang.c is a
Usenet newsgroup; Google Groups does not own it.

In general, the trick is to find a forum where your questions are
topical. There may be a Usenet newsgroup that fits your needs. If
not, Google Groups may have some non-Usenet group.

[...]

Well,
The "simple" library without malloc is needed because I was told
malloc is not well implemented on this terminal, and should not be
used. I was actually using malloc in my program before, without any
problems, but I removed all of them under that advice, and I'd like to
keep it safe and go without it because I'm not sure why malloc could
be such an issue for the terminal. But even using just static memory
the regular C "string" is a pain, to mention the less.

I don't know what you mean by "terminal". Are you working with some
kind of embedded system?

If you need dynamically allocated storage that's can be deallocated
before the program terminates, and that doesn't vanish at the end of
the scope in which it's created, then malloc() and friends are the
only tool the C language offers. If your implementations's malloc()
is somehow broken, you may be able to roll your own. For example, you
might declare a sufficiently large static array, and provide your own
functions to allocate chunks from it. I think K&R2 has a sample
memory allocator; it might be instructive.

If you don't need the full generality of malloc, realloc, and free,
that might make rolling your own a bit simpler. For example, if all
your allocations are the same size, you don't need to worry about
fragmentation. If your allocated chunks of memory are always going to
be deallocated in the reverse of the order in which they were
allocated, you can use a stack-like scheme. And so on.

[snip]

 

[Cawas]

When posting a followup, you should usually quote the relevant parts
of the parent article. See most of the articles here for examples.
See also <http://cfaj.freeshell.org/google/>. In this particular
case, your followup is probably clear enough without quoted context,
but keep it in mind for future postings.

Cool, but that far I knew from my forums experience, I did not quote
in purpose. ;-)

You need to be aware that Google Groups is *not* Usenet. Usenet is a
distributed discussion forum that has existed for several decades.
Google Groups is, among other things, an archive of Usenet and a
(sometimes rather inconvenient) interface to it. comp.lang.c is a
Usenet newsgroup; Google Groups does not own it.

In general, the trick is to find a forum where your questions are
topical. There may be a Usenet newsgroup that fits your needs. If
not, Google Groups may have some non-Usenet group.

Hmm, I did read the overview ( http://groups.google.com/intl/en/googlegroups/overview.html
) and the tour. I just did it again now, and I could not find where it
says something about being an interface to usenet, but I do remember I
read somewhere that it had archives from usenet (maybe it was
wikipedia) but I was led to believe usenet didn't exist anymore, or at
least that google groups was not linked to it, just had archives.

For one, I was really thinking of it as forums, rather than
newsgroups. I never liked newgroups due to the "spam nature" of it.
Back when Netscape Navigator were popular, and we could choose to
receive e-mails and newsgroups... That was awfull! Oh well, maybe this
is still the closest to the major forum that I was hoping to exist by
today. I've tried to find regular forums in the past, but I still
couldn't find a place that feels like home. I'm still hoping it could
be google groups + usenet, however it should be called.

I don't know what you mean by "terminal". Are you working with some
kind of embedded system?

That's it. Embedded system. Sorry about that. *adding new word to
vocabulary*.

But I still think that at least the vprintf thing belongs here.

If you need dynamically allocated storage that's can be deallocated
before the program terminates, [...]

Yeah, I don't quite need, and *I hope* I've never said that I did,
dynamically allocated storage. But I never thought about building my
own malloc, that could be intersting. This system is, after all,
limited. It has very little memory. One of them have just 200kb RAM,
and that's for storage. Being able to use malloc could be nice or even
needed eventually, but it could also lead to more problems in the
later case. I'll certainlly look for that later on, but that was not
the only problem I had with implementing bstring.

Now... I just wonder if I should add my next reply in here, or make a
new one as this GG interface suggessts.

 

[Richard Heathfield]

Cawas said:

Hmm, I did read the overview (
http://groups.google.com/intl/en/googlegroups/overview.html ) and the
tour. I just did it again now, and I could not find where it says
something about being an interface to usenet, but I do remember I read
somewhere that it had archives from usenet (maybe it was wikipedia)
but I was led to believe usenet didn't exist anymore,

You were led to believe wrong. If Google ceased to exist *right now*,
the only effect on comp.lang.c would be that the signal-to-noise ratio
would increase slightly.

 

[Default User]

Cawas wrote:

Hmm, I did read the overview (
http://groups.google.com/intl/en/googlegroups/overview.html ) and the
tour. I just did it again now, and I could not find where it says
something about being an interface to usenet, but I do remember I
read somewhere that it had archives from usenet (maybe it was
wikipedia) but I was led to believe usenet didn't exist anymore, or
at least that google groups was not linked to it, just had archives.

You didn't read the right stuff.

<http://groups.google.com/support/bin/answer.py?answer=46854&topic=9246>





Brian

 

[websnarf]

Cipher Lab produces some terminals to collect data where we can
program using one implementation of plain C which I believe to be ANSI
C89 compatible, although not fully. They have their on set of
libraries as well, but all in all, it's basic C we're talking about.

[...] Particularly, I'd love to know if someone could sucessfully use
any well known string library on it, such as Paul Hsieh's bstring
(http://bstring.sourceforge.net), although I doubt it. And I know for
experience that it would be nice to share some custom made libraries
to solve lots of troubles on those terminals, since I've been
painfully building one myself, from scratch.

Why do you doubt it? The Better String Library needs about 20K or so
of code space. Other than that it optionally uses the vsnprintf()
function (which some compilers don't support) but that's all explained
in the porting guide. As long as your compiler is fairly close to
ANSI C 89, there should be no problem. The Better String Library is
*very* portable to most ANSI (or near-ANSI) C compilers.

IBM held a kind of "massive porting effort" of a bunch of libraries on
source forge to their Linux on Power systems. The Better String
Library had a "non-issue" warning in the examples that was fixed with,
an 8 character change -- otherwise it worked perfectly.

The next "topics" I'll try to bring are:
1. strings - I think 90% of all troubles I'm having are from trying to
manipulate them. A good simple workaround library, which does not use
malloc, would be greatly appreciated. But maybe I'll just finish my
own soon enough.

The Better String Library uses malloc. You might like to look at
firestring as a library that has a non-malloc sub-library for strings.

4. stdarg.h - it does not have va_copy, but I'm not having an issue
with that. Although I'd love to see an implementation of va_copy since
I have no idea how to write it, my problem here is on using it to
create my own vprintf. I could create a "dprintf" that works just
fine, but I've wanted to expand it, making a rdprintf that would use
dprintf. For that, I need to create a vdprintf, and that's where I
can't go beyond.

You should look through the Better String Library's bvformata() macro
for insight into how this was accomplished in a C89 portable way.

 

[Cawas]

For some reason, Ggroups ate my answer to this.... Let me do it again,
and renewed.

Cawas wrote, On 16/05/07 16:03:



Making a mistake is fine.



Firstly, this is not Google Groups. Google Groups is merely one
interface on to a far larger thing called Usenet, something that existed
before Google existed.



No. There is a procedure for creating groups, a procedure that has
nothing to do with Google, and I doubt that you would succeed.

I suggest you look for mailing lists dedicated to your system.

Also, if your system is an embedded system then comp.arch.embedded may
be able to offer some assistance.

<snip>

That's really good to know. But creating a group in ggroups seems
fairly easy, maybe I'll try this later on, when I have something (or
at least some people) to start it with.

First rule of optimisation, don't do it. If the performance of your
application was fine with malloc and that was the clearest way to write
it you should have stuck with it. Something I've learnt is that many of
the "don't do this because it is inefficient" suggestions are no longer
relevant because technology has moved on. Also, it is easier to speed up
a working and clearly written program than to get a fast but hard to
read program working correctly.

I agree with you, but I didn't see it as optimization, I was thinking
in preventing bugs. I don't know why they told me to keep away from
malloc, and I know questioning it could be troublesome. Maybe there's
nothing wrong with this malloc implementation, but now I've changed
everything to work without it anyway. That wasn't a problem.

And it wasn't the clearest way, but I started with it because I hate
static things. I'd use as many variables as possible. Still, making
things dynamic (with malloc) in C is way more confusing than keeping
it static.

<snip>

You might be surprised. He has certainly been prepared to halp on far
simpler things.

I'm already surprised now.
Evenmore cuz it seems he uses ggroups, or at least a gmail.

From the sounds of this comp.arch.embedded may well be a better place
for initial questioning.

So far no good. Maybe I'll try to shake my post there a little bit.
Plus, I've stoped trying to fix this for now, but I think it belongs
here anyway. It is, most likely, something wrong in some obscure part
of my code, of course, but it seems to me it's something related to
variable types.

<snip>

I'm guessing that the problem is that you do not have a prototype in
scope and you need one. When splitting a project in to multiple files it
is normal to do something like:

/* foo.h */
#ifndef H_FOO
#define H_FOO

unsigned long foo(unsigned long x);

#endif

/* foo.c */
#include "foo.h"

unsigned long foo(unsigned long x)
{
return x * 3;

}

/* main.c */
#include "foo.h"
...

This way the compiler always knows the correct types of everything.
Otherwise it is required to make assumptions that are not always true.

I wonder what assumptions. And that's a good guess, but wouldn't that
bring troubles to calling the function altogether, rather than
troubles with just one parameter? I mean, my actual function do have
more parameters, and that one I'm using in foo is just its last one.
Plus, as I said, there's just 1 scope. Unless the pre-compiler does
not include files as I assumed from the name that it would.

I've made few more tests with it, and foo() also works fine if I call
it from main. It does not work just from inside a few functions I've
tried. One of them looks like this:

int write_read (int nPort, const char header[], const char term[]) {
char buff[200+1];
char stxt[120+1], saux[120+1], crc[2+1];
int result, i, t = 0;

foo(DELAY);
/* code of function goes here */

return result;
}

As soon as the function starts, if I try to call not foo, but the
similar function, it already brings a big number (last time was
1940851640), but if I call bar, everything works fine. I don't know
how this could be related to the function, but the fact is if I try
calling my "foo_alike" function from some places, it works, and from
other places, it does not (keeping in mind "bar_alike" works always).

Also, I'm printing just ("%d,%d", delay, final_msec) now, so the
1940851640 comes directly from delay.

I may be drawing the wrong picture, but that's what seems weird to me:

- a function calls foo(5000)
- foo prints 1940851640
- the same function calls bar() in the very next line (or previous)
- bar calls foo(5000)
- foo prints 5000

Anyway, don't worry too much about this, it seems it's something un-
guessable. I just thought there was a chance that I might be doing
something really wrong and the symptoms would reveal it easily, so I
just tried to describe the symptom.

And I did get around it with using the bar(), although it is an
intriguing fix.

int __CDECL vprintf (const char *format, va_list arg) {
char prt[200+1];
vsprintf(prt, format, arg);
return puts(prt);
}

Keep in mind malloc is not an option. That works, but I wonder what
would be a better way to write it.

Why can you not use vprintf? My first guess would be that you were using
it incorrectly, and solving that problem would be better than working
around it.

If I try to use vprintf the linker brings me this error:
TULINK-Error-209: Reference made to unresolved external symbol
"_vprintf"

I've checked, it's actually on the header file, but probably not in
the library, for any reason. Plus, vsprintf do work.

<snip>

Nothing looks wrong in the above, assuming your use of non-standard
functions is correct and you have included the correct headers for all
of the functions.

You can assume that.
It does not matter, if you get the point of what I want. But...

<snip>

Here is a major problem. If you do not provide a small complete example
that actually shows the problem we don't stand much chance of diagnosing
it. Consider that if you do not know what is causing the problem then
you do not know it is in part of the code you are not showing. You may
also find that in cutting the program down to a failing example small
enough to post you actually find the problem.

This advice applies to any group you are posting to, including
comp.arch.embedded which I *think* might be an appropriate group.

.... It seems you didn't get my point here. I'm not having a problem at
this point (4). I just want to write an implementation similar to what
vprintf is to printf. So, just seeing those implemented would be
enough to me, but I couldn't find them. In fact, just vprintf must be
enough, but since I'm not sure how this works, I'd go for printf as
well.

I'm still trying to follow Paul's advice on bvformata() tho... But I
still couldn't find it... *back to replying to Paul*

 

[Cawas]

It seems like Ggroups failed to deliver my last reply, once again...
Maybe I can't post one few minutes after the other. The really bad
side is that I've lost what I've written then.

Cipher Lab produces some terminals to collect data where we can
program using one implementation of plain C which I believe to be ANSI
C89 compatible, although not fully. They have their own set of
libraries as well, but all in all, it's basic C we're talking about.

[...] Particularly, I'd love to know if someone could sucessfully use
any well known string library on it, such as Paul Hsieh's bstring
(http://bstring.sourceforge.net), although I doubt it. And I know for
experience that it would be nice to share some custom made libraries
to solve lots of troubles on those terminals, since I've been
painfully building one myself, from scratch.

Why do you doubt it? The Better String Library needs about 20K or so
of code space. Other than that it optionally uses the vsnprintf()
function (which some compilers don't support) but that's all explained
in the porting guide. As long as your compiler is fairly close to
ANSI C 89, there should be no problem. The Better String Library is
*very* portable to most ANSI (or near-ANSI) C compilers.

IBM held a kind of "massive porting effort" of a bunch of libraries on
source forge to their Linux on Power systems. The Better String
Library had a "non-issue" warning in the examples that was fixed with,
an 8 character change -- otherwise it worked perfectly.

For a number of reasons. One of them is the "not fully" compatible.
I'm not sure what is missing, I haven't compared the headers with the
ANSI C89 standard, if that would be enough to know it. But there is
that malloc issue and vprintf seems to not be in this library. Don't
get me wrong, I'd love to point things to fix in bstring, but I'm not
that expert just yet. I'm blaming this system I'm using for not being
able to take bstring, not the other way around.

stdio.h, for example, does not have snprintf at all, and it does have
vprintf (which does not work when linking, as mentioned in my previous
post). There are lots of lines commented out, saying "not support",
but those are mostly ok, since they deal with files, and the embedded
system has its own file system.

The Better String Library uses malloc. You might like to look at
firestring as a library that has a non-malloc sub-library for strings.

Hmm... sub-library, huh? That might work, I'll sure try it.

You should look through the Better String Library's bvformata() macro
for insight into how this was accomplished in a C89 portable way.

Yeah, sure. I'm already using bstring as a reference for lot of
things, even if I can't use it directly. It's always good to see a
working and well commented library. I did look for something like this
in it before, but I couldn't find it. I had the 01232007 one, I guess
it wasn't there yet. So I've downloaded the new one, 03312007, and
there it was!

But it still doesn't help me much.

Basically, I can easily find anywhere how to make a function(...) to
call a function(va_list), and in bstring now I could see a
function(va_list) calling another function(va_list), which now I know
doesn't need to use va_start, and that was bvcformata calling
vsnprintf via macro. But I want to make a function(...) to call
another function(...) and since vprintf exists, I figured that it is
not possible. So I figured I'd need to build a function(va_list) to
call the function(...) so the cycle can be closed.

I didn't thought at first it would be this hard to find some code
showing that.

 

[CBFalconer]

It seems like Ggroups failed to deliver my last reply, once again...
Maybe I can't post one few minutes after the other. The really bad
side is that I've lost what I've written then.

It is high time you installed a real newsreader and accessed a real
news server. In addition, this is off-topic for c.l.c.

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

--
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/> (taming google)
<http://members.fortunecity.com/nnqweb/> (newusers)

 

[David Thompson]

Basically, I can easily find anywhere how to make a function(...) to
call a function(va_list), and in bstring now I could see a
function(va_list) calling another function(va_list), which now I know
doesn't need to use va_start, and that was bvcformata calling
vsnprintf via macro. But I want to make a function(...) to call
another function(...) and since vprintf exists, I figured that it is
not possible. So I figured I'd need to build a function(va_list) to
call the function(...) so the cycle can be closed.

Right, it's not possible standardly and portably to construct a call
with variable arguments. You can have multiple calls (sites), each
with different argument types, to one (x, ...) routine, assuming that
routine is able to handle those types, but each call has a fixed list
of types. The closest you can come is something like:
void (*f_v) (int,...) = somevarargfunction;
int (*f_i) (int,...) = (int(*)(int,...) f_v;
...
int int_ret, int_1; double real_2; char * str_3 = malloc (x);
switch( encoded_arg_types ){
/* if you can represent your cases in an int value;
if you need a string or struct or something, do
a series of if(strcmp( )) ... else or similar instead */
case VOID_ARGS_INT_STR: (void) (*f_v) (int_1, str_3); break;
case INT_ARGS_INT_REAL: int_ret = (*f_i) (int_1, real_2); break;
...
}
(Aside: You don't actually need the explicit deref (*fptr) (args),
just fptr (args) will work, but I show it for emphasis.)

I didn't thought at first it would be this hard to find some code
showing that.

This is precisely why the approach commonly recommended, including the
FAQ, and used, is to have a 'real/core' routine that takes a va_list,
which can then be called from a vararg wrapper(s) or through any
number of levels of va_list routines, as long as in portable C89 you
only go through each 'original' list once, and with va_copy in C99 (or
as an extension) you don't even have that limitation.

- formerly david.thompson1 || achar(64) || worldnet.att.net