Re: Cipher Lab / Syntech

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.

<snip>

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. :P

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.
--
Flash Gordon

.

Relevant Pages

  • Re: about the array
    ... return int and take an unknown number and type of arguments. ... void *ptr; ... if the declaration of malloc() isn't visible, ... attempting to assign an int to a void*. ...
    (comp.lang.c)
  • Re: Question regarding malloc casing
    ... With out prototype compiler assumes that malloc returns int. ... malloc, which returns (void *). ...
    (comp.lang.c)
  • Re: sizeof(ptr) = ?
    ... Imagine a machine on which addresses are simple integers, and 'char *' values can point to any address, but 'int *' values can only point to addresses which have a multiple of 4 due to alignment problems. ... The values returned from malloc() are always suitably aligned for any type, and so are restricted to valid values of all pointer types. ... because in general there are more valid 'void *' values than ...
    (comp.lang.c)
  • Re: Unknown function
    ... How can the function call of 'malloc' work at all if it is unknown? ... I thought that each function that is unknown to the compiler at a specific ... returns an int. ... problem since malloc actually takes size_t and returns void *. ...
    (comp.lang.c)
  • Re: Inconsistent Program Results
    ... void rdinput; ... you need to test that restrict is not NULL before ... Don't cast the result of malloc(). ...
    (comp.lang.c)