GLubyte and "+="

[PeterO]

I'm updating some openGL ES code, and since I now compile my code with lots more gcc warnings enabled I've run into this brain teaser

This code

Code: Select all

GLubyte step;
for(step = 0; step < POINTS; step += 1)

produces this warning

Code: Select all

warning: conversion to ‘GLubyte {aka unsigned char}’ from ‘int’ may alter its value [-Wconversion]
     for(step = 0; step < POINTS; step += 1)
                                          ^

and I can't work out how to avoid the warning. I could change the type of "step" but it should be a GLubyte because it gets passed to a function that takes a GLubyte as a parameter.

PeterO

PS: Yes I know it is only a warning, but I'm trying to get my code into a state where it compiles cleanly in preparation for releasing it.

[SkyRise]

Hi PeterO

A little confused. You declare "step" as a GLubyte, but then go on to mention that a later function requires it to be a GLuint.
Wouldn't just declaring "step" as a GLuint help?

[Edit: No code expert here, just happened to look at your post...]

[PeterO]

Hi PeterO

A little confused. You declare "step" as a GLubyte, but then go on to mention that a later function requires it to be a GLuint.
Wouldn't just declaring "step" as a GLuint help?

[Edit: No code expert here, just happened to look at your post...]

Ah, typo, now fixed, thanks.
PeterO

[jahboater]

Also, using "++step" instead of "step += 1" solves the problem too.

step += 1 is the same as step = step + 1. "step + 1" gets promoted to integer, and then that int is assigned to the smaller char type, which raises the warning. There is no separate expression when using ++, so no promotion.

[PeterO]

Also, using "++step" instead of "step += 1" solves the problem too.

step += 1 is the same as step = step + 1. "step + 1" gets promoted to integer, and then that int is assigned to the smaller char type, which raises the warning. There is no separate expression when using ++, so no promotion.

Yes I understand the issues, but using ++ is not an answer as I also have problem elsewhere with "step += 2"
I think what I need is a way to express the "1" so that no type promotion takes place. I could have an GLubyte variable set to one I suppose, but that feels messy. (And actually doesn't work now that I try it !)

The integer promotion rule seems destined to cause lots of warnings with -Wconversion enabled

PeterO

[jahboater]

The integer promotion rule seems destined to cause lots of warnings with -Wconversion enabled

You can blame ARM and other CPU's that cannot properly do arithmetic on anything smaller than a 32 bit "int". Intel CPU's have 16-bit and 8-bit registers that can do all types of arithmetic correctly. So to be on the safe side everything gets promoted to int

Note the compiler doesn't pedantically warn about things like this all the time.
For example:

step |= 2

would not raise a warning because, although it is a narrowing conversion, no loss of data can possibly occur, so it is always safe.

Your choice to use GLuint is best.

Otherwise for 2, this horrid cast would be needed

step = (GLubyte)(step + 2);

Nasty

[PeterO]

I've decided to make step an plain old int and just cast it to GLubyte when it is assigned or used as parameter.
Seems to be the most readable solution.

It's also lead me down a rabbit hole about using size_t since my code uses calloc (which takes two size_t parameters) to make arrays of GLfloats to hold vertices of some computed objects.

I'm sure this is all part of getting older as I'm sure I never used to worry about this sort of stuff if the code worked
PeterO

[jahboater]

I'm sure this is all part of getting older as I'm sure I never used to worry about this sort of stuff if the code worked

Same here!
I suppose being retired now I have more time to be fussy and get everything right ...

Also compilers have much better diagnostics in recent years.

[PeterO]

I'm sure this is all part of getting older as I'm sure I never used to worry about this sort of stuff if the code worked

Same here!
I suppose being retired now I have more time to be fussy and get everything right ...

Yes you are right! With no project managers chasing us for delivery dates (which I was notoriously bad at predicting) we can take the time to "do it right"

Also compilers have much better diagnostics in recent years.

Yes, I only recently noticed gcc has started making helpful suggestions when you mistype variable/function names like this ..

Code: Select all

error: ‘nearX’ undeclared (first use in this function); did you mean ‘nearZ’?
     if ( (nearX <= 0.0f) || (farZ <= 0.0f) ||
           ^~~~~
           nearZ

PeteO

[PeterO]

Well I got the code working, with a 100% clean compile I might add :
But it seems I've changed some scaling factors in my openGLES toolkit since I last used the button drawing code

WG2.png (15.75 KiB) Viewed 2974 times

PeterO