Thread: Quick check for potential problems

Doesn't look like anyone was gonna respond (no biggie in this case) however I did experience some problems with it, eventually went with this:

Code:

int alu_mov( alu_t *alu, uintptr_t num, uintptr_t val, size_t size )
{
	int ret = 0, tmp = -1;
	void *ptr;
	alu_reg_t *REG;
	
	if ( num >= ALU_REG_ID_LIMIT )
	{
		if ( val >= ALU_REG_ID_LIMIT )
		{
			errno = 0;
			(void)memmove( (void*)num, (void*)val, size );
			ret = errno;
			return ret;
		}
		
		ret = alu_check2( alu, ALU_REG_ID_NEED, val );
		
		if ( ret != 0 )
		{
			alu_error( ret );
			return ret;
		}
		
		ret = alu_get_reg( alu, &tmp );
		
		if ( ret != 0 )
		{
			alu_error( ret );
			return ret;
		}
		
		ptr = (void*)num;
		REG = (alu->regv + tmp);
		
		alu__or( alu, tmp, val );
		
		(void)memset( ptr, 0, size );
		
		if ( size > alu->buff.perN )
			size = alu->buff.perN;
		
		(void)memmove( ptr, REG->part, size );
		
		(void)alu_rem_reg( alu, tmp );
		return 0;
	}
	
	if ( val >= ALU_REG_ID_LIMIT )
	{	
		ret = alu_check1( alu, num );
		
		if ( ret != 0 )
		{
			alu_error( ret );
			return ret;
		}
		
		ret = alu_get_reg( alu, &tmp );
		
		if ( ret != 0 )
		{
			alu_error( ret );
			return ret;
		}
		
		ptr = (void*)val;
		REG = (alu->regv + tmp);
		
		if ( size > alu->buff.perN )
			size = alu->buff.perN;
		
		(void)memmove( REG->part, ptr, size );
		
		(void)alu_xor( alu, num, num );
		(void)alu__or( alu, num, tmp );
		
		(void)alu_rem_reg( alu, tmp );
		return 0;
	}
	
	alu_xor( alu, num, num );
	alu__or( alu, num, val );
	
	return ret;
}

Originally Posted by laserlight

Isn't that the kind of typo a compiler or even an IDE's code analysis will tell you about? You shouldn't need to ask for help in finding that kind of mistakes in a forum.

It wasn't the kind of bug I was asking for a check for, I just figured someone would eventually bring it up so headed it off.

Originally Posted by laserlight

We're part of the same online forum community, but that doesn't mean we're team mates who already have some idea of what your code does. So, by not providing context, e.g., properly documenting your code, you're not making it any easier for potential helpers to want to bother with your code.

Wasn't the function name enough context? ALU standing for Arithmetic Logic Unit and then mov was clearly a reference to the mov cpu instruction

Originally Posted by laserlight

Nope. People don't necessarily immediately know what "ALU" stands for without context (I only happened to know from reading your previous posts), and without that it is easy to guess that "mov" means "move" but not so easy to guess what does a "move" actually mean to you here. Then even knowing what alu_mov means, do you really expect the reader to know what's the background behind what looks like an attempt to simulate opcodes and to guess what exactly what the parameters mean?

Sure, go ahead and continue posting these if they help you: sometimes just asking for help can be enough to help you get an "aha!" moment with your own code. But if you really want random community members to help you, you need to look at things from the fresh perspective of someone who might have no clue what you've been doing, having seen you and your post for the very first time. If they have an introduction into what you're trying to do, can read documentation at least for the functions that are part of your library's interface, can compile and run test code... you'll be putting yourself at an advantage to receive help. It's no guarantee you'll get help, of course, but even if you don't you'll be making your library more usable and it'll help you go through your code from a fresh perspective, which can help uncover unwarranted assumptions etc.

If you really don't want to put in the effort to do this, that's fine too, but chances are higher people are going to gloss over your code, go "what is this", and move on.

I figured anyone with an interest in programming would also have an interest in how the cpu understands that code and come across the ALU naturally, am I mistaken there?

Originally Posted by I C everything

I have seen many of those posts,is there a final goal like some cpu emulator,a final big switch(opcode)/case with opcodes list, calling your library?

Well I plan to use it both in the hobby c compiler I'm trying to make and in gasp, a separate project I started because I got tired of how slow and unresponsive GameConqueror is. For the compiler the project is needed just for reading in floats/double/long doubles and basically any sized FPN (cause I already made a version that works on slower code with no fixed size). For gasp it's just a case of supporting extra because I can.

Switching topic, I made this for the char section in my fallback limits header and figured I might as well ask if anyone see's any problems

Code:

#ifndef CHAR_SIGNED
# if defined( __CHAR_UNSIGNED__ )
# elif defined( __CHAR_SIGNED__ )
#  define CHAR_SIGNED
# elif ('\0'|(1 << (CHAR_BIT-1))) < 0
#  define CHAR_SIGNED
# endif
#endif

#ifndef CHAR_UNSIGNED
# ifndef CHAR_SIGNED
#  define CHAR_UNSIGNED
# endif
#endif

#ifndef CHAR_MAX
# ifdef CHAR_SIGNED
#  define CHAR_MAX SCHAR_MAX
# else
#  define CHAR_MAX UCHAR_MAX
# endif
#endif

#ifndef CHAR_MIN
# ifdef CHAR_SIGNED
#  define CHAR_MIN SCHAR_MIN
# else
#  define CHAR_MIN 0u
# endif
#endif

Full project here: fbstdc

Here's a problem:

Code:

#ifndef CHAR_SIGNED
# if defined( __CHAR_UNSIGNED__ )
# elif defined( __CHAR_SIGNED__ )
#  define CHAR_SIGNED
# elif ('\0'|(1 << (CHAR_BIT-1))) < 0
#  define CHAR_SIGNED
# endif
#endif

More specifically this line:

Code:

# elif ('\0'|(1 << (CHAR_BIT-1))) < 0

will probably not work as intended because a character literal like '\0' has type int, not char (though I don't know if the preprocessor follows the same rules as the compiler proper).

Besides, when would you ever care whether char is signed or unsigned? If you need an unsigned or signed char, use unsigned char or signed char (or use one of the standard types like uint8_t or int8_t if you need a small numeric type). Otherwise, use a plain char.

If you insist on having macros for this, how about this:

Code:

#define CHAR_SIGNED ((char)-1 < 0)
#define CHAR_UNSIGNED (!CHAR_SIGNED)

which are evaluated by the compiler proper (any halfway-decent compiler from the last 30 years will very likely optimize them out because they're compile-time constants).

I don't understand what the '\0' is for in

Originally Posted by awsdert

# elif ('\0'|(1 << (CHAR_BIT-1))) < 0

Putting 0 on the left hand side of a bitwise or makes no sense (because you may as well no have the bitwise or at all) and might make the reviewer (me in this case) think that the programmer has made a typo or doesn't understand what a bitwise OR does. I'd be just as suspicious of something like if (0 + 4) < blah ... What's the 0 there for? If it's intentional then I'd expect the programmer to provide a comment

Originally Posted by Hodor

I don't understand what the '\0' is for in


Putting 0 on the left hand side of a bitwise or makes no sense (because you may as well no have the bitwise or at all) and might make the reviewer (me in this case) think that the programmer has made a typo or doesn't understand what a bitwise OR does. I'd be just as suspicious of something like if (0 + 4) < blah ... What's the 0 there for? If it's intentional then I'd expect the programmer to provide a comment

I needed the character but am trying to keep it from being promoted to an integer, that was the best I could come up with, I also figured it might not work so I asked here, it's a very rare situation that it would actually be used but still want to make sure it works, if you got a better idea that doesn't rely on CHAR_MAX & CHAR_MIN I'm all eyes

Originally Posted by christop

If you insist on having macros for this, how about this:

Code:

#define CHAR_SIGNED ((char)-1 < 0)
#define CHAR_UNSIGNED (!CHAR_SIGNED)

which are evaluated by the compiler proper (any halfway-decent compiler from the last 30 years will very likely optimize them out because they're compile-time constants).

The problem is these macros need to be used in the precompiler and from experience the #if/#elif treat casts as an error meaning I cannot use (char) as much as I would like to