understanding the error code returned by sce* functions...?

[smartie_on_computer]

Hey Devs,

i need a little help, i know that some of the higher, more experienced devs here can understand an error code that is produced by sce based functions.

im just trying out some code and when i call this function

Code: Select all

result = sceUsbCamSetupVideo(&videoparam, work, sizeof(work));	
	if &#40;result < 0&#41;
	&#123;
		printf&#40;"Error 0x%08X in sceUsbCamSetupVideo.\n", result&#41;;
		return result;
	&#125;

it fails and returns:

Code: Select all

Error 0x80243903 in sceUsbCamSetupVideo.

what does that error code mean?

[smartie_on_computer]

nothing? these forums aren't as active as they used to be :(

[TyRaNiD]

Well that error code isn't in the ones which came from puzzle bobble's debug symbols so there is really little way to tell what it means :)

[smartie_on_computer]

Well that error code isn't in the ones which came from puzzle bobble's debug symbols so there is really little way to tell what it means :)

so pretty much, sony have a whole list of error codes or probably a debug function that looks up error codes and prints out a error stating whats wrong?

[Torch]

The SDK hardware is probably connected to a PC for realtime remote debugging or something like that. Hence it would be compiled with debug info while testing (which the release build shouldn't but apparently they screwed up on that part with Puzzle Bobble.)

[smartie_on_computer]

ok i guess that would make sense too...

i solved the problem by the way, i replaced "sizeof(work)" with "(68*1024)"

'work' is a pointer to a byte array and i guess sizeof was unable to figure out how big it was

[J.F.]

ok i guess that would make sense too...

i solved the problem by the way, i replaced "sizeof(work)" with "(68*1024)"

'work' is a pointer to a byte array and i guess sizeof was unable to figure out how big it was

The size of a pointer is the size of the pointer, not what it points to. :)

[smartie_on_computer]

The size of a pointer is the size of the pointer, not what it points to. :)

Yeah, i figured that. how would i figure out the size of what the pointer points to?

[cheriff]

The size of a pointer is the size of the pointer, not what it points to. :)

Yeah, i figured that. how would i figure out the size of what the pointer points to?

Assuming "struct foo *work;"

I usually use sizeof(struct foo) ie, taking the size of the type rather than the variable.

Although increasingly I'm liking sizeof(*work) which does the same thing, and allows you to change the name of the struct that 'work' is without having to find all the sizeof's in your codebase.

I'm not sure which is 'better' in any way, shape or form, others here may have better arguments for or against ...

[Torch]

sizeof(*pointer) should return the correct size assuming that its pointing to a statically declared thing (or size of array if it points to the first element).

[smartie_on_computer]

yeah, i cant do that because i've declared a byte away globally and passed a pointer to it to a class, so when it compiles, its unable to determine the size of the byte array, instead i'll just use a #define WORK_SIZE 64*1024

Thanks for all your guys help
Cheers
Roman

[SilverSpring]

The work size has to be a multiple of 64. That error means the size arg is incorrect, ie. not a multiple of 64 (I just checked the function).

A lot of error codes are not documented so you have to check the function yourself to see what the error means.